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FOREWORD 


The  Multiplexed  Data  Bus  Conference  was  requested  by 
Lt  Gen  Marsh,  Vice  Couander  of  Air  Force  Systeas  Coaaand , 
and  la  being  hosted  by  ASD,  Maj  Gen  Sylvester,  Coaaander. 

The  purpose  of  the  Conference  Is  to  collect  data  on  multl- 
plex  experience  by  the  Air  Force,  Navy,  Aray,  NASA  and 
Industry  In  order  to  assist  In  the  ln-house  preparation  of 
a MIL-STD-1553A  Multiplex  Specification  and  Design  Handbook. 

It  also  Is  Intended  to  be  an  excellent  neans  for  Inforaatlon 
exchange  between  current  prograas  and,  at  the  saae  tlae,  to 
provide  an  education  to  future  users  of  aultlplexed  digital 
avionics . 

Many  thanks  to  Captain  Robert  W.  Johnson  (AF5C/XRF) 
for  his  headquarters'  assistance  In  organizing  this  con- 
ference and  especially  to  Mr.  Allen  J.  Cannon  (ASD/ENAZ) 
who  did  an  outstanding  job  In  organizing  the  conference 
facilities  and  exhibits. 

Thanks  also  to  the  moderators  and  all  the  speakers 
who  responded  with  outstanding  papers  In  a timely  Banner 
despite  such  short  notice.  And,  finally  to  Mrs.  Marie  Jankovlch 
for  her  expert  administrative  help  In  handling  the  conference 
correspondence  and  registration. 

C- 

ERWIN  C.  GANGL,  Technical  Advisor 
ASD/ENAI 

Conference  Organizer 
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RCP1  V TO 
ATTN  Or 

SUBJECT: 

TO: 


DEPARTMENT  OF  THE  AIR  FORCE 

MCAOOUARTERS  AIR  FORCE  SYSTEMS  COMMAND 
ANDREWS  AIR  FORCE  dASE,  DC  MJ14 

CV  g\  AUG  1976 

Multiplex  Data  Bus  Conference 
ASD/CC  CV 


1.  We  would  appreciate  your  hosting  a conference  on  Multiplex  Data 
Buses.  Digital  avionics  in  aeronautical  systems  are  currently  receiving 
a considerable  amount  of  management  attention.  Integration  of  digital 
avionics  is  centered  upon  the  multiplex  data  bus  concept  and  M1L-STD- 
1553A  has  been  developed  to  standardize  this  concept.  Recent 
experiences  with  using  this  Triservice  standard  indicate  a need  for 
improved  guidance  on  its  application.  The  conference  would  afford 
us  the  opportunity  to  assimilate  information  for  development  of  a 
Multiplex  Data  Bus  Design  Handbook. 


2.  We  propose  to  assemble  experts  from  DDR&E,  Air  Staff,  AFSC, 
Navy,  Army,  NASA,  and  industry  to  discuss  the  application  experience 
of  multiplexed  data  buses.  The  conference  would  considerably  shorten 
the  data  gathering  phase  for  the  handbook,  provide  a means  for  informa- 
tion exchange  between  current  programs  and  provide  an  education  to 
future  users  of  digital  avionics. 


^3.  The  AFSC  project  officer.  Captain  Robert  W.  Johnson  (AFSC/XRF, 
AUTOVON  858-2652),  is  prepared  to  assist  the  ASD  staff  in  arranging 
the  details  of  this  conference. 


ROBERT  T.  MARSH,  Lt  Sen,  USAS' 
Vloe  Commander 
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THE  DESIGN  AND  DEVELOPMENT  OF  THE 


F- 15  AVIONICS  DATA  BUS 
By  John  F.  Susek 
McDonnell  Aircraft  Company 
St.  Louis,  Missouri 


ABSTRACT 


This  paper  describes  the  Digital  Time  Division  Multiplex 
Command/Response  Data  Bus  designed  for  the  F-15  Avionics  Sub- 
system. Design  requirements  are  specified  in  MCAIR  Report 
H009,  "F-15  Digital  Interface  Design  Specification."  The  F-15 
Data  Bus  is  used  to  exchange  data  between  the  central  Mission 
Computer  and  major  sets  of  the  avionics  subsystems.  The  sys- 
tem architecture  using  dual  redundant  party  line  data  buses 
and  dedicated  back-up  buses  is  discussed.  Many  of  the  detail 
design  characteristics  of  the  F-15  Data  Bus  or  similar  require- 
ments were  incorporated  in  MIL-STD-1553A.  The  salient  features 
of  the  F-15  Data  Bus  are  described;  the  diffences  from  1553A 
are  noted  and  discussed.  The  principal  difference  is  in  the 
method  of  obtaining  a reference  clock  signal  in  the  terminal; 
i.e.,  separate  clock  line  versus  self  clocking  data.  Another 
is  the  use  of  unterminated  transmission  lines  in  the  F-15. 
Studies  and  tests  contributing  to  the  development  of  the  system 
are  outlined.  Some  of  the  system  characteristics  which  are 
considered  to  be  very  important  for  proper  system  operation  are 
discussed . 

1.  BACKGROUND 

The  need  for  an  avionics  data  bus  became  apparent  during 
MCAIR' s initial  response  to  the  F-15  RFP  in  late  1968.  The 
concept  of  using  a digital  multiplexing  system  for  a majority 
of  the  data  exchanges  in  an  avionics  subsystem  was  new  to  many 
engineers  both  at  MCAIR  and  at  our  potential  avionics  suppliers. 
IR1G  Std-106  and  MIL-STD-442  were  the  basic  standards  for  mul- 
tiplexed data  transmission  at  that  time.  These  standards  were 
primarily  designed  for  telemetry  systems  to  be  used  in  instru- 
mentation applications,  and  were  not  considered  suitable  for  an 
avionics  data  bus.  As  a result,  it  was  necessary  for  MCAIR  to 
develop  a multiplex  system  specification  applicable  to  all  F-15 
avionics  sets  which  were  to  interface  with  the  data  bus.  MCAIR 
Report  H009,  "F-15  Digital  Interface  Design  Specification," 


was  created. 


The  H009  Report  defines  a standard  interface  by  specify- 
ing the  characteristics  of  the  signals  on  the  bus,  plus  the 
operating  procedure  and  data  format  for  transferring  data  over 
the  bus.  It  was  not  intended  to  specify  a multiplex  terminal 
detailed  configuration,  only  operational  performance.  A mul- 
tiplex terminal  compatible  with  the  specified  interface  is 
supplied  as  an  integral  part  of  each  avionics  set  by  the  set 
supplier,  with  the  reliability  and  qualification  requirements 
for  the  terminal  included  in  those  specified  for  the  set. 

The  F-15  multiplex  system  was  designed  to  satisfy  a very 
specific  requirement;  i.e.,  the  exchange  of  digital  data 
between  the  central  computer  and  major  sets  of  a highly  inte- 
grated avionics  subsystem  installed  in  an  F-15  Air  Superiority 
Fighter  Aircraft.  Because  of  the  limited  time  and  budget 
available  prior  to  placing  contract  awards  for  F-15  subsystems, 
time  available  to  optimize  the  design  was  limited.  Precontract 
award  efforts  were  directed  toward  developing  a practical  spec- 
ification which  provided  sufficient  margin  for  relatively  low 
risk  development  and  operation  of  the  system,  considering  the 
variety  of  sources  for  terminals  and  the  uncertainty  of  a new 
aircraft  electromagnetic  environment.  After  the  F-15  contract 
was  awarded  and  avionics  set  suppliers  were  under  contract,  no 
opportunity  to  materially  change  the  design  without  seriously 
affecting  all  these  contracts  would  exist;  therefore,  it  was 
necessary  to  have  a workable  design  prior  to  contract  go-ahead 
in  January  1970. 

2.  SYSTEM  ARCHITECTURE 

The  F-15  Avionics  Subsystem  employes  a hierarchal  archi- 
tecture made  up  of  a number  of  sets  containing  digital  data 
processors  which  vary  in  size  and  capability.  Therefore,  a digi- 
tal time  division  multiplex  (TDM)  party  line  bus  is  an  obvious 
choice  to  handle  data  exchanges.  The  data  bus  architecture  is 
illustrated  in  Figure  1. 

The  central  mission  computer  (MC)  peforms  mission  oriented 
computations  which  generally  involve  data  inputs  from  more  than 
one  set  and  exercises  overall  control  of  the  avionics  subsystem, 
including  operating  as  the  bus  controller.  The  mission  computer 
either  uses  or  generates  most  of  the  data  on  the  bus;  there  is 
very  little  requirement  for  data  exchanges  directly  between 
peripheral  sets  over  the  data  buses.  Therefore,  the  multiplex 
system  is  designed  so  that  all  data  exchanges  go  through  the  MC 
and  no  direct  peripheral- to-peripheral  transfers  are  made.  As 
a result,  the  MC  data  bus  and  peripheral  unit  multiplex  termi- 
nals operate  as  an  extension  of  the  computer  I/O  using  Command/ 
Response  operation.  The  MC  only  controls  the  transmission  and 
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reception  of  data  from  peripheral  terminals  and  associated  buf- 
fer memories;  it  does  not  exercise  control  over  any  data  pro- 
cessing or  conversion  in  peripheral  units  other  than  to  command 
subsystem  operating  mode  in  response  to  the  pilot's  selection 
of  desired  system  modes  of  operation. 


Since  the  majority  of  data  exchanges  in  the  avionics  sub- 
system are  handled  over  the  multiplexed  data  bus,  a redundant 
bus  is  provided  to  increase  communication  reliability.  Either 
of  the  two  data  buses  can  handle  data  at  any  time  but  only  one 
of  the  redundant  pairs  can  be  active  at  any  one  time.  The  bus 
to  be  used  for  each  data  exchange  is  selected  by  the  MC  on  the 
basis  of  current  performance.  Each  of  the  buses  uses  two, 
shielded  twisted  pair  transmission  lines;  one  for  data  signals 
and  one  for  clock  signals.  In  addition,  the  data  bus  is  divided 
into  two  separate  redundant  pairs,  each  servicing  six  sets. 

This  reduces  the  number  of  peripherals  serviced  through  a single 
MC  terminal  with  the  object  of  reducing  bus  traffic,  the  elec- 
trical load  on  the  bus,  and  the  physical  length  of  the  bus. 

This  division  was  made  early  in  the  design  to  minimize  the  risk 
due  to  uncertainties  in  estimating  bus  traffic  and  the  impact 
of  adding  growth  terminals. 


There  are  two  one  way  dedicated  buses  in  the  F-15  avionics 
system  in  addition  to  the  MC  data  buses.  Both  of  these  use  the 
same  signal  and  data  formats  as  the  MC  bus,  but  use  a discrete 
signal  over  a separate  line  to  request  data  rather  than  a Select 
Word  sent  over  the  data  bus.  One  bus  operates  between  the  Iner- 
tial Navigation  Set  (INS)  or  the  Attitude  Heading  Reference  Set 
(AHRS)  and  the  Radar.  The  INS  supplies  attitude  data  to  the 
Radar  at  a much  higher  (250  sample/second)  data  rate  than  the 
MC,  which  operates  at  a rate  of  20  samples  a second.  If  the  INS 
is  NO  GO,  the  AHRS  senses  this  condition  and  responds  to  the 
request  for  data  from  the  Radar.  The  Head-Up  Display  (HUD)  also 
listens  on  this  bus  and  uses  attitude  information  from  this  bus 
for  a back-up  display  if  the  MC  is  not  supplying  attitude  data. 
The  second  bus  is  used  to  transmit  gun  sight  data  from  the  Lead 
Computing  Gyro  (LCG)  to  the  HUD.  If  the  HUD  cannot  get  the 
required  data  from  the  MC  bus,  it  switches  over  to  the  LCG  bus 
and  requests  alternative  gun  sight  data.  This  provides  a back- 
up gun  mode  which  is  independent  of  the  MC. 


3. 


DESIGN 


The  salient  design  features  of  the  F-15  Avionics  Data  Bus 
are  very  similar  to  MIL-STD-1553  in  many  respects.  In  my  dis- 
cussion, I will  only  note  the  differences.  The  F-15  Data  Bus 
is  a party  line  bus  using  digital  time  division  multiplexing 
and  operating  in  the  half  duplex  mode.  Bus  traffic  is  con- 
trolled by  the  mission  computer  (bus  controller)  using  command/ 
response  techniques.  Data  words  which  contain  16  data  bits 


5 


f 

I 


t 

'I 

f 

I 


i 


f 

f 


plus  a parity  bit  are  transmitted  in  variable  length  messages 
of  from  1 to  15  words.  (1553  allows  up  to  32  words  in  a mes- 
sage.) The  addressee  or  source  and  contents  of  the  message 
are  defined  in  the  Select  Word  which  precedes  all  messages. 
(1553  uses  a Command  Word  which  carries  the  same  information 
in  a different  format.)  See  Fi^jcre  2.  Data  bits  are  trans- 
mitted at  a rate  of  1 Mbps,  using  base  band  PCM  with  biphase 
coding,  over  a shielded  twisted  pair  (STP)  transmission  line 
having  a characteristic  impedance  of  68  ohms.  (1553  use  a 70 
ohm  STP . ) 

Multiplex  terminals  are  transformer  coupled  to  the  line 
in  a balanced- to-ground , center-tap  grounded,  configuration. 
(1553  does  not  specify  grounded  center  tap.)  Terminals  pre- 
sent a high  impedance  (5K  ohm  resistive  component  at  1 MHz) 
to  the  transmission  line  in  the  receiving  mode.  (1553  speci- 
fies 2K  ohms  at  100K  Hz  to  1 MHz.)  In  the  transmitting  mode, 
the  source  impedance  of  the  terminal  is  68  ohms.  (1553  does 
not  specify  a source  impedance,  but  specifies  two  52.5  ohm 
isolating  resistors  in  series  with  the  output.)  Signal  levels 
on  the  line  are  10  +2  volts  line-to-line  with  a minimum  level 
at  the  receiver  specified  at  2 volts;  tests  indicate  this 
lower  level  is  very  rarely  seen.  (1553  specifies  3 to  10 
volts  line-to-line  with  a minimum  of  0.5  volts.)  The  F-15 
receiver  operates  with  a 1 volt  threshold  level;  signals  or 
noise  below  this  level  are  considered  to  represent  a "No  Data" 
state.  This  implementation  provides  a tri-state  signal.  A 
data  bit  code  validity  check  is  also  used  to  identify  valid 
data  bits  from  No  Data.  This  check  verifies  that  the  signal 
polarity  during  the  second  half  of  the  bit  period  is  the  oppo- 
site polarity  of  the  signal  detected  during  the  first  half. 

The  signals  appearing  on  the  transmission  line  very 
closely  resemble  1 MHz  sine  waves  since  the  harmonic  content 
of  the  data  is  limited  above  1.5  MHz.  Data  signals  which  are 
all  logical  one's  or  all  logical  zero's  look  like  1 MHz  sine 
waves.  Data  signals  of  alternating  logical  one's  and  zero's 
are  500  KHz  sine  waves  mixed  with  1.5  MHz  3rd  harmonic  compo- 
nents. This  produces  a wave  form  with  a zero  transition  which 
very  closely  approximates  the  zero  transition  of  a 1 MHz  sine 
wave. 

The  F-15  Data  Bus  uses  a 1 MHz  reference  clock  signal 
generated  in  the  mission  computer  and  distributed  to  all  the 
peripherals  over  a clock  transmission  line  separate  from  the 
data  line.  (1553  generates  a reference  clock  signal  from  the 
data  signal  in  each  terminal.)  This  reference  clock  is  used 
for  synchronous  bit  detection  and  word  handling.  It  also 
allows  word  and  message  synchronization  without  the  use  of 
special  synch  pulses  or  additional  special  bit  patterns.  Data 
words  on  the  bus  are  in  exactly  the  same  form  as  the  data  in 
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the  computer  memory  and  terminal  logic.  See  Figure  2.  The 
absence  of  valid  data  signal;  i.e.,  no  valid  biphase  signals 
above  the  threshold,  on  the  data  line  for  eight  reference 
clock  periods  indicates  a new  message  is  to  be  initiated  and 
directs  all  terminals  to  resynchronize  and  prepare  to  receive 
a new  Select  Word.  (1553  uses  a 3 usee  period  of  invalid  code 
immediately  preceding  the  Command  Word.) 

Data  words  in  a message  are  separated  by  gaps,  no  data  on 
the  line,  of  exactly  five  clock  periods.  (1553  uses  a 3 usee 
period  of  invalid  code  to  separate  words  in  a message.)  Data 
transmissions  from  a peripheral  in  response  to  a Select  Word 
follow  that  word  by  exactly  5 reference  clock  periods.  (1553 
requires  a response  to  a Command  Word  in  2 to  5 usee.)  Data 
bits  from  the  peripheral  are  transmitted  in  phase  with  the 
reference  clock  from  the  MC;  therefore,  they  are  out  of  phase 
with  the  clock  when  received  at  the  computer.  This  phase  dif- 
ference is  approximately  twice  the  propagation  time  from  the 
computer  to  the  peripheral.  If  the  total  line  length  is  no 
greater  than  70  feet,  these  delays  are  tolerable  and  do  not 
affect  synchronous  handling  of  data  at  the  computer. 

The  reference  clock  signal  is  also  used  to  identify  which 
of  the  two  redundant  buses  is  to  be  used  for  data  transmissions. 
When  the  mission  computer  wishes  to  use  one  of  the  two  redun- 
dant buses,  the  reference  clock  signal  is  brought  up  on  the 
clock  line  of  the  selected  bus.  Clock  signals  look  exactly 
like  data  signals  of  all  logical  one's;  i.e.,  a 1 MHz  sine  wave. 
The  presence  of  a clock  signal  on  a bus  for  more  than  8 clock 
periods,  with  no  data  on  the  bus,  indicates  a new  message  will 
be  initiated  on  that  bus.  If  the  clock  signal  goes  down  while 
a terminal  is  transmitting,  the  transmitter  is  shut  down  and  all 
the  peripheral  terminals  go  the  Receive  Mode,  resynchronize  and 
prepare  to  receive  a new  Select  Word.  This  type  of  resynchro- 
nization is  used  if  the  MC  recognizes  transmission  of  format 
errors  on  the  bus;  i.e.,  invalid  data  bits,  parity  errors,  incor- 
rect word  length  or  spacing.  Dropping  the  clock  signal  can  also 
signify  a terminal  is  to  cease  transmissions  because  the  mission 
computer  wants  to  regain  control  of  the  bus. 

The  shielded  twisted  pair  transmission  line  used  to  imple- 
ment the  F-15  data  buses  is  very  similar  to  regular  aircraft 
wire,  except  that  the  characteristic  impedance  is  controlled  to 
68  +4  ohms.  The  fabrication  and  performance  of  this  wire  is 
controlled  by  a MCAIR  Standard.  The  data  and  clock  bus  cables 
are  incorporated  into  aircraft  wire  bundles  using  standard  con- 
nectors without  special  handling.  Regular  line  splices  are 
used  to  connect  the  lines,  except  that  the  splices  are  shielded 
to  reduce  emissions.  No  special  coupling  boxes  (as  described 
in  1553)  were  used  because  this  concept  is  not  compatible  with 
F-15  wire  bundle  fabrication  and  installation  in  the  compact 
avionic  compartments  of  the  F-15. 


The  receiving  branches  of  the  bus  network  are  terminated 
by  the  high  input  impedance  of  the  terminals.  No  transmission 
line  terminating  resistors  are  used  at  the  ends  of  the  line. 
(1553  uses  two  terminating  resistors,  each  equal  to  the  char- 
acteristic impedance  of  the  line.)  The  transmission  line  has 
a multi-forked  character  in  the  bus  network  configuration 
resulting  from  the  compact  wiring  installation  in  the  aircraft. 
This  is  particularly  true  when  viewing  the  bus  network  from 
all  the  various  subscriber  terminals  which  will  be  used  as 
driving  points.  The  terminal  transmitters  have  a source  imped- 
ance equal  to  the  characteristic  impedance  of  the  line,  which 
minimizes  secondary  reflections  from  the  driving  point.  Since 
the  total  transmission  line  length  (approximately  70  feet)  is 
a small  portion  of  an  electrical  wave  length  at  the  primary 
frequency  of  1 MHz  and  frequencies  higher  than  1.5  MHz  are 
attenuated  prior  to  transmission,  the  primary  reflections  do 
not  produce  significant  signal  wave  form  distortion. 

4.  DEVELOPMENT 

The  initial  development  effort  was  directed  toward  the 
investigation  of  the  effects  of  multiple  loads  on  a transmis- 
sion line  which  might  be  driven  at  any  point.  This  condition 
represents  one  of  the  major  operational  problems  of  a party 
line  data  bus.  Shielded  twisted  pair  operating  as  a balanced 
line,  with  transformer  coupling,  biphase  PCM  coding,  high  level 
voltage  type  line  drivers,  etc.,  were  system  characteristics 
which  had  been  previously  studied  and  used.  These  character- 
istics were  selected  as  a sound  basis  for  a system  that  would 
present  low  developmental  risk. 

A simple  program  was  written  for  MCAIR's  direct  access 
computer  and  used  to  analyze  voltage  levels  and  waveforms  on 
a simulated  transmission  line.  Our  analyses  showed  that  no 
significant  waveform  distortion  is  produced  when  operating  into 
an  unterminated  line;  if  the  harmonic  content  of  the  signals  is 
limited,  the  line  length  is  less  than  about  one  tenth  of  a wave 
length  (70  feet)  and  re-reflections  from  the  driver  are  mini- 
mized. We  also  investigated  the  effects  of  adding  loading  or 
terminating  resistors  at  various  points  on  the  network.  Our 
conclusion  was  that  loading  resistors  could  be  added  to  reduce 
reflections  or  possible  resonance  conditions  if  necessary. 
Operating  signal  voltage  levels  were  chosen  to  be  high  enough 
so  that  loading  resistors  could  be  added  without  reducing  sig- 
nals to  unusable  levels.  Laboratory  tests  on  transmission 
lines  with  a simulated  line  driver  and  dummy  loads  for  termi- 
nals were  used  to  verify  the  analytical  results.  A breadboard 
of  the  digital  logic  needed  for  handling  data  words  and  mes- 
sages was  fabricated  and  used  to  demonstrate  the  Command/ 
Response  party  line  bus  operational  concept. 
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A meeting  of  design  engineers  from  all  affected  avionics 
suppliers  was  held  early  in  the  hardware  design  phase.  During 
this  meeting,  many  details  of  data  bus  operation  and  terminal 
design  were  discussed.  Mutual  agreement  was  reached  on  seve- 
ral minor  specification  changes  and  system  details  were  better 
defined.  During  the  course  of  hardware  development,  there 
were  many  exchanges  of  ideas  and  concepts  between  MCAIR  and 
the  supplier  hardware  designers.  After  the  development  of 
hardware  had  progressed  to  the  breadboard  stage,  many  suppliers 
accepted  our  invitation  to  bring  their  terminal  breadboards 
into  MCAIR  for  test  with  the  MC  or  our  laboratory  test  benches. 
This  was  possible  since  the  first  MC  was  delivered  early  in  the 
program  and  the  avionics  test  benches  were  designed  and  fabri- 
cated in  the  MCAIR  Avionics  Laboratory.  These  early  tests  were 
quite  valuable  in  that  they  provided  the  opportunity  for  the 
early  discovery  and  correction  of  a number  of  minor  problems, 
but  more  importantly,  they  raised  the  confidence  level  of  the 
designers  and  their  management. 

All  the  preproduction  hardware  was  tested  on  special  MCAIR 
test  benches  after  delivery.  These  benches  used  a simulated 
MC  I/O  for  communicating  with  the  set.  Successful  operation 
on  these  benches  further  verified  data  bus  terminal  operation 
and  uncovered  other  minor  problems.  Further  integration  tests 
with  major  groups  of  sets;  i.e.,  two  or  three  sets  with  the  MC, 
verified  actual  party  line  operation.  The  final  laboratory 
system  tests  were  conducted  in  the  Avionics  Integration  Mockup. 
The  mockup  of  the  F-15  nose,  cockpit  and  avionics  compartment 
was  fabricated  from  "tooling  test"  aluminum  structure  and  skins, 
which  were  assembled  to  production  drawings.  Wire  bundles  made 
to  production  drawings  were  installed  along  with  preproduction 
avionics  hardware.  Extensive  tests  of  the  system  in  this  mock- 
up,  which  duplicated  the  forward  section  of  the  F-15,  verified 
that  the  data  bus  was  operating  satisfactorily  with  a complete 
avionics  suite. 

The  first  inflight  tests  of  the  data  bus  were  made  in  a 
WB-66D  aircraft  which  was  used  as  a flying  test  bed  for  F-15 
avionics  prior  to  the  F-15  flight  test  program.  The  test  sys- 
tem included  an  F-15  Radar,  INS  and  MC , plus  a MCAIR  designed 
and  fabricated  simulator  which  provided  data  responses  for 
peripheral  sets  which  were  not  installed  in  the  test  aircraft. 
This  test  program  was  primarily  designed  to  provide  early  eval- 
uation and  flight  development  of  the  F-15  Radar,  INS  and  other 
F-15  avionics,  but  also  it  provided  an  opportunity  to  verify 
data  bus  operation  in  flight. 

Early  in  the  F-15  flight  test  program,  tests  made  on  the 
aircraft  wiring  indicated  the  transmission  line  cable  being 
supplied  was  very  much  out  of  tolerance.  The  capacitance  per 
foot  was  much  greater  than  the  specification  and  consequently, 
the  propagation  factor  was  much  lower  than  specified.  The 
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problem  was  resolved  by  the  cable  supplier  who  changed  the 
cable  insulation  material  from  Kapton  & Teflon  to  all  Teflon, 
which  improved  the  dielectric  constant  of  the  insulation. 

The  new  cable  met  specification  and  improved  system  perfor- 
mance since  it  eliminated  some  of  the  excessive  time  delays 
experienced  with  the  first  cable.  Further  evaluation  during 
over  4000  F-15  test  flights  verified  that  the  data  bus  system 
performed  as  predicted  with  no  system  problems. 

5.  CONCLUSIONS 

The  satisfactory  operation  of  the  F-15  data  bus  terminals 
in  all  of  the  preproduction  avionics  sets  was  a very  signifi- 
cant factor  in  the  successful  develooment  of  the  F-15  Avionics 
Subsystem.  Data  bus  terminals  were  built  into  individual  avi- 
onics sets;  therefore,  these  sets  could  not  have  been  tested 
and  evaluated  if  the  interface  with  the  data  bus  was  not  oper- 
ating. Many  benefits  can  be  realized  from  a standard  interface 
and  party  line  bus  operation  during  initial  testing  and  inte- 
gration of  an  avionics  subsystem  if  the  interface  terminals 
perform  properly.  But  if  the  interface  does  not  perform  well, 
even  on  the  first  item  delivered,  the  penalties  of  these  delays 
early  in  the  program  can  be  extremely  serious.  We  feel  that 
all  efforts  expended  in  both  the  design  and  development  of  the 
F-15  data  bus  to  assure  a workable  interface  in  the  first  de- 
livered units  were  very  worthwhile. 

I would  like  to  mention  some  of  the  characteristics  of 
the  system  which  are  considered  to  be  important  by  MCAIR  engi- 
neers associated  with  the  design  and  development  of  the  F-15 
data  bus. 


Bandwidth  limiting  of  data  signals  improves  the  perfor- 
mance of  a data  bus  with  the  transmission  line  discontinuities 
accompanying  party  line  operation.  Attaching  terminals  with 
stubs  and/or  splices  at  many  points  on  a transmission  line  pro- 
duces line  discontinuities.  These  discontinuities  vary  in 
severity  as  a function  of  where  the  line  is  driven  and  the  con- 
dition of  all  the  terminals  on  the  line.  Maintaining  high 
level  signals  with  good  wave  form  over  the  entire  length  of  the 
bus  is  considered  to  be  the  best  deterrent  to  interference  from 
external  sources. 

The  rejection  of  line  noise  by  the  use  of  a relatively 
high  detection  threshold  level  reduces  the  probability  of  pro- 
cessing noise  as  data.  A data  bit  validity  check;  i.e.,  com- 
paring the  first  half  of  the  data  bit  with  the  complement  of 
the  second  half,  the  primary  method  of  detecting  transmission 
errors  on  the  F-15  data  bus  is  backed  up  with  both  parity  and 
word  length  checks.  Although  data  errors  have  never  been  a 
problem,  it  is  believed  most  transmission  errors  are  detected  as 
invalid  data  bits,  and  the  data  word  is  rejected  before  invalid 
parity  or  improper  word  length  can  be  recognized. 
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Suppressing  the  higher  harmonics  in  the  data  signals 
also  reduces  the  possibility  of  high  frequency  radiation  from 
the  transmission  line.  Data  signals  are  not  the  only  source 
of  high  frequency  radiation  from  the  data  bus.  Noise  gene- 
rated by  high  speed  clocks  and  switching  in  a digital  proces- 
sor can  be  coupled  to  the  line  terminals.  The  wide  band  high 
frequency  port  provided  by  the  terminal  and  data  bus  can  thus 
provide  a means  for  radiating  internal  noise  if  not  properly 
isolated  from  other  circuitry  in  the  box.  One  solution  to 
this  problem  is  shielding  wire  bundles  that  carry  data  bus 
lines  with  an  overall  braid.  This  was  not  an  acceptable  solu- 
tion from  the  standpoint  of  weight,  manufacturing  and  mainte- 
nance, and  was  not  used  in  the  F-15. 

The  use  of  a common  reference  clock  signal,  rather  than 
extracting  the  clock  from  the  data,  simplifies  the  F-15  data 
bus  terminal  for  the  price  of  the  added  wiring  and  provides 
additional  control  over  data  transmission,  synchronization  and 
detection.  The  gain  in  terminal  design  simplicity  with  today's 
experience  and  advanced  technology  is  probably  not  a very  sig- 
nificant factor.  For  some  applications,  the  line  length  limi- 
tation experienced  by  the  F-15  data  bus  is  a more  significant 
factor.  The  F-15  data  bus  has  been  operated  at  line  lengths 
up  to  100  feet  but  operating  with  this  length  of  line  leaves 
little  margin  and  is  not  recommended.  The  line  length  limita- 
tion imposed  on  the  F-15  bus  by  bit  synchronous  operation  is 
also  compatible  with  the  use  of  an  unloaded  or  unterminated 
line;  this  simplified  the  transmission  line  installation. 

The  most  important  characteristic  of  the  F-15  data  bus, 
from  my  point  of  view,  is  that  it  does  what  it  was  designed  to 
do;  it  transfers  digital  data  between  the  central  computer  and 
major  sets  of  the  F-15  avionics  subsystem.  The  F-15  aircraft 
has  been  operational  since  December  1975  and  more  than  100  air- 
craft have  been  delivered  to  date.  The  reports  received  indi- 
cate the  performance  of  the  F-15  Avionics  Subsystem  and  data 
bus  have  been  very  satisfactory. 
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Barry  D.  McLaren  is  a senior  engineering  supervisor  with 
Boeing  Aerospace  Company,  a Division  of  The  Boeing  Company 
of  Seattle.  For  the  past  three  years  he  has  been  responsi- 
ble for  circuit  design  and  development  of  the  avionics 
hardware  manufactured  directly  by  Boeing  for  navigation, 
penetration  and  weapon  management  functions  to  be  employed 
on  B-l.  He  has  39  engineers  reporting  to  him  in  this 
capacity . 

His  previous  experience  includes  several  years  of  detailed 
circuit  design  and  project  engineering  experience  on  the 
SRAM  B-52  Carrier  Avionics,  F-lll  Stores  Management  test 
equipment  and  several  other  power  conversion  and  signal 
multiplexing  equipment  for  SST,  DC-9,  727,  and  737  aircraft. 

Mr.  McLaren  has  been  involved  in  the  design  of  time  division 
multiplex  equipment  utilizing  pulse  code  modulating  tech- 
niques since  1966.  On  his  present  assignment  he  was  directly 
involved  in  the  evolvement  of  the  multiplexing  system  con- 
cepts established  for  the  B-l  Avionics  System  and  participated 
directly  in  the  circuit  development  for  this  data  network. 
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B-l  AVIONICS  DATA  MULTIPLEXING  SYSTEM  (AMUX) 

Barry  D.  McLaren 
Boeing  Aerospace  Company 
(a  division  of  The  Boeing  Company) 
Seattle,  Washington 


ABSTRACT 

In  recent  years  time  division  multiplexing  has  become  an 
accepted  technique  for  data  transfer  in  avionics  weapon  systems 
as  a means  of  significantly  reducing  wiring  weight  and  complexity 
and  increasing  signal  transfer  capability  and  reliability. 

This  paper  describes  Boeing's  B-l  Avionics  multiplexing  system 
from  conception  of  the  system  approach  to  discussion  of  detailed 
circuit  design  concepts.  It  also  discusses  flexibility  of  the 
system  to  accommodate  additional  requirements  and  increased 
functional  capabilities 

Introduction 

Basically,  Boeing's  avionics  system  integrates  the  necessary 
hardware  and  software  to  permit  the  B-l  Bomber  to  meet  its 
navigation,  penetration  and  weapon  delivery  requirements. 

Figure  1,  a cutaway  of  the  aircraft  showing  the  quantity  and  loca- 
tion of  the  various  equipments  that  make  up  the  Avionics  System, 
illustrates  why  data  transfer  by  multiplexing  techniques  was  a 
necessity  for  keeping  cabling  between  remote  hardware  within 
reasonable  weight  limits.  Several  additional  objectives  were 
realized  with  the  development  of  this  multiplexing 
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system.  For  example,  maintaining  flexibility  in  the  hardware 
design  to  accommodate  unexpected  integration  problems  with 
existing  equipment  and  new,  as  yet  undefined  equipment,  was 
considered  essential.  Structuring  the  equipment  and  system 
architecture  for  ample  growth  over  the  life  of  the  aircraft  was 
also  important.  Standardizing  interface  requirements  and  circuitry 
will  reduce  life  cycle  costs  of  this  equipment  and  will  help 
minimize  hardware  proliferation  when  additional  requirements  are 
implemented. 

This  paper  discusses  the  multiplexing  system  developed  by  Boeing 
for  use  in  the  B-l  Avionics.  An  overview  of  the  system  architec- 
ture will  be  discussed  first  to  provide  familiarization  with  the 
requirements  of  the  multiplexing  system.  The  data  link  itself 
is  then  described  both  with  regard  to  its  functional  character- 
istics and  its  electrical  interface  requirements.  The  interface 
circuitry  utilized  by  all  Boeing  built  hardware,  referred  to  as 
the  I/O  MODEM,  is  then  presented.  Finally,  the  follow-on  growth, 
demonstrated  with  a discussion  on  how  the  Defensive  System  Segment 
is  being  implemented,  is  presented. 


FIGURE  1.  B-l  AVIONICS  INTEGRATION 
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System  Design 


The  Offensive  System  of  the  B-l  Avionics  equipment  is  broadly 
categorized  into  four  general  subsystems  as  defined  below  and 
illustrated  in  Figure  2: 


a.  Avionics  Control  Unit  Complex 

b.  Controls  and  Displays  Subsystem 

c.  Navigation  and  Weapon  Delivery  Subsystem 

d.  Stores  Management  Subsystem 

All  navigation  and  weapon  delivery  functions  are  controlled  with- 
in the  two  computers  of  the  Avionics  Control  Unit  Complex,  the 
heart  of  the  B-l  Avionics  System.  The  General  Navigation  Avionics 
Control  Unit  (GNACU)  and  the  Weapon  Delivery  Avionics  Control  Unit 
(WDACU)  are  general  purpose  avionics  computers  (see  Figure  3) 
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which  are  identical  and  inter- 
changeable. Each  is  capable 
of  absorbing  the  mission  func- 
tions of  the  other  in  the  event 
of  an  equipment  malfunction. 
Both  have  parallel  data  access 
to  the  Mass  Memory,  a 600K  word 
drum  storage  unit,  for  roll-in 
of  computer  programs,  certain 
off-line  processing  or  data 
storage. 


The  Avionics  Contrcl  Unit 
Complex  also  contains  four  FIGURE  3.  ACU  INTERNAL  ORGANIZATION 

types  of  remote  terminal  units 

for  interfacing  Government  Furnished  Equipment  (GFE)  to  the  Avionics 
System.  Each  employs  identical  architecture  (see  Figure  4)  and,  to 
the  extent  possible,  common  circuitry.  The  Forward  Looking  Radar 
Data  Terminal  converts  serial-digital,  AC  and  DC  discretes  and  synchro 
data,  both  to  and  from  the  APQ-144  Forward  Looking  Radar  (FLR) , into 
a format  compatible  with  the  data  flow  on  the  multiplexing  system. 

The  Terrain  Following  Radar  Data  Terminal  performs  essentially  the 
same  functions  with  different  types  of  signals  in  interfacing  with 
the  APQ-146  Terrain  Following  Radar  (TFR)  system. 
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The  third  remote  terminal  device  is  the  Interface  Adapter  Unit 
(IAU) . There  are  two  IAU's  aboard  each  aircraft  for  interfacing 
two  separate  Radar  Altimeters  (APN-194)  and  a single  Doppler 
Radar  (APN-200)  with  the  multiplexing  system.  The  IAU's  also 
separately  monitor  certain  diagnostic  discretes  from  the  two 
ACU's  and  interface  with  the  aircraft  Electrical  Multiplexing 
System  (EMUX)  for  transfer  of  Avionics  power  management  and 
control  data.  The  fourth  unit,  the  Buffer  Conversion  Unit  (BCU) 
converts  various  monitoring  and  test  point  data  from  Mission  and 
Traffic  Control  (M&TC)  equipment  to  digital  format  for  software 
verification  of  M&TC  operability. 

The  Control  and  Displays  Subsystem  is  composed  of  thirteen 
separate  C&D  panels  and  display  equipment.  Four  of  these  items 
actually  interface  with  the  multiplex  system  for  C&D  data  trans- 
fer between  the  ACUs  and  the  thirteen  panels.  They  are  the 
Integrated  Keyboard  (IKB) , the  Symbol  Generator  (SYM  GEN) , the 
Stores  Master  Panel  and  the  Navigation  Control  Panel.  The  IKB 
provides  the  means  by  which  the  Offensive  Systems  Officer  identi- 
fies and  selects  various  computer  program  options.  The  SYM  GEN 
converts  the  digital  data  received  on  the  multiplex  system  into 
video  data  for  CRT  displays.  The  other  two  panel  functions  are 
sel f-explanatory . 

The  Navigation  and  Weapon  Delivery  Subsystem  contains  two  Inertial 
Electronics  Units  each  of  which  convert  torquer,  accelerometer 
and  synchro  data  for  a corresponding  Inertial  Platform  (LN-15)  to 
the  multiplex  format. 

The  Stores  Management  Subsystem  contains  three  types  of  Station 
Logic  Units  which  are  basically  special  purpose  remote  terminals. 
Each  of  these  items  are  designed  to  interface  with  a specific 
type  of  weapon  (SRAM  missile  or  Nuclear  bomb)  and  convert  the 
interface  signals  from  these  weapons  to  the  multiplex  format  for 
data  transfer. 

AMUX  Multiplex  System 

All  data  transfer  between  the  GNACU , the  WDACU  and  the  various 
remote  terminals  is  mechanized  via  the  AMUX  multiplex  system 
which  is  basically  a network  of  5 data  channels  as  shown  in 
Figure  5. 

Two  of  the  AMUX  channels  (CHNL  1 and  2)  interface  with  subsystem 
line  replaceable  units  (LRUs)  associated  with  general  navigation 
functions  and  are  directly  controlled  by  the  GNACU.  channels  3 
and  4 generally  interface  with  subsystems  associated  with  weapon 
delivery  functions  and  are  controlled  by  the  WDACU.  This  permits 
both  ACUs  to  simultaneously  transfer  data  to  corresponding  sub- 
systems without  interferring  with  one  another's  operation. 

Channel  5 is  the  single  AMUX  channel  utilized  for  Central  Inte- 
grated Test  System  test  functions  which,  under  normal  operating 
conditions,  is  carried  out  by  the  WDACU  software. 
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FIGURE  5.  B-l  AVIONICS  MULTIPLEXING 


During  normal  operation,  both  ACUs  implement  inter-ACU  data 
transfer  as  a part  of  the  normal  scheduled  I/O  on  the  AMUX  lines. 
The  GNACU  implements  data  transfer  to  the  WDACU  via  either  channel 
1 or  2 and  the  WDACU  responds  like  any  other  subsystem  LRU.  The 
WDACU  initiates  data  transfer  with  the  GNACU  in  the  same  manner 
using  channels  3 and  4.  Therefore,  no  race  conditions  or  simul- 
taneous transmission  (head-butting)  is  encountered  by  the  two 
machines  during  inter-ACU  I/O  operations. 

Each  ACU  operates  utilizing 
a 62-1/2  millisecond  main- 
frame period  which  is  sub- 
divided into  four  minor  frames 
such  that  the  GNACU  performs 
scheduled  I/O  in  the  first 
and  third  minor  frames  and 
carries  out  processing  opera- 
tions in  the  second  and  fourth. 

Concurrently,  the  WDACU  trans- 
fers scheduled  I/O  in  the 
second  and  fourth  minor  frames 
and  affects  processing  in  the 
first  and  third.  (This  operational  sequence  is  shown  in  Figure  6). 
Since  both  ACUs  interface  with  all  AMUX  lines  and  can  carry  out 
processing  and  data  transfer  functions  simultaneously,  either 
ACU  can  assume  all  avionics  operations,  in  the  event  of  a failure 
in  the  other,  by  interleaving  the  processing  and  I/O  functions. 

Each  machine  retains  a copy  of  the  other's  executive  program  in 


CMCII 


scot  ia>  I ■»  i scot  i/a  I CM 


WMCU 


_citj | scot  i/o  | unrnn  | scot  i/o  | 


FIGURE  6. 

SCHEDULED  ACU  I/O  SEQUENCE 
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resident  core  and  both  interchange  data  tables  each  major  frame 
via  inter-ACU  I/O  so  that  nearly  continuous  operation  is  maintain- 
ed during  changeover  to  single  ACU  operation. 

Each  serial  channel  is  a bi-directional  serial -digital  data  link 
which  transfers  time  division  multiplexed  data  between  all  inter- 
facing subsystems  and  the  GNACU  or  WDACU.  Data  is  coded  per  pulse 
code  modulation  techniques  at  a 1 meg-bit/second  data  rate.  Each 
subsystem  or  LRU  has  a dual  redundant  AMUX  data  link  interface 
such  that  any  one  data  link  failure  will  not  disable  communica- 
tions to  any  LRU  (the  only  exceptions  are  the  BCU  and  CITS  inter- 
faces which  are  not  mission  critical  and  therefore  employ  only  a 
single  AMUX  interface) . 

Data  transfer  is  always  initiated  by  an  ACU  on  one  of  the  two 
redundant  data  links  and  data  transfer  with  an  LRU  is  always 
directly  to  or  from  an  ACU  on  the  activated  Data  Link.  Three  types 
of  word  formats  are  used  in  accomplishing  a data  transfer  sequence. 
They  are  Command  Words,  Response  Words  and  Data  Words  as  shown  in 
Figure  7.  The  Command  Word  format  identifies  the  subsystem  LRU 
being  activated  and  the  mode  of  operation  required.  These  words 
are  transmitted  only  by  ACU's.  The  Response  Word  is  utilized  by 
the  responding  subsystem  to  acknowledge  data  transfer  and  to 
report  the  validity  of  that  transfer.  The  Data  Word  format 
contains  the  actual  data  being  transferred,  either  as  packed 
discretes  or  as  binary  data  (usually  in  two's  complement  format). 
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During  subsystem  reception  the  activated  subsystem  validates 
all  incoming  data.  The  integrity  of  each  incoming  word  is  veri- 
fied according  to  the  following  criteria: 

a.  Valid  address 

b.  Sync  Code 

d.  Word  length 

e.  Parity 

f.  Data  Validity 

g.  Message  length 

If  a subsystem  LRU  detects  a Command  Word  that  fails  criteria  (a) 
through  (f) , the  command  is  considered  invalid  and  no  action  is 
taken  with  regard  to  it  or  the  remainder  of  the  message.  If  the 
Command  Word  is  properly  received  but  any  part  of  the  remainder 
of  the  message  fails  to  conform  with  criteria  (b)  through  (g) , 
the  affected  area  and  remainder  of  the  message  is  considered 
invalid  (and  therefore  not  used)  and,  upon  completion  of  the  data 
transfer,  the  subsystem  will  transmit  a Response  Word  with  the 
"V"  bit  set  to  a logic  "1"  to  indicate  an  error  has  been  detected 

The  ACU  validates  incoming  data  from  each  subsystem  according  to 
the  same  criteria.  However,  ACU  action  in  the  event  of  a data 
error  depends  primarily  on  system  requirements.  For  example, 
when  an  ACU  detects  no  response  from  an  addressed  LRU  or  detects 
a Response  Word  with  the  "V"  bit  set,  it  will  execute  a retry  on 
the  alternate  AMUX  line  unless  a retry  has  already  been  attempted 
In  the  latter  case,  a number  of  additional  alternatives  can  be 
taken  depending  on  the  nature  of  the  data  (additional  retries  may 
be  attempted,  the  other  ACU  may  attempt  communication  with  the 
affected  LRU,  the  LRU  may  be  declared  no-go,  etc.). 

Figure  10  is  an  example  of  what  one  would  observe  monitoring  one 
of  the  AMUX  data  links,  differentially,  with  an  oscilloscope. 

All  words  within  a message  are  always  appended  to  one  another. 
However,  gaps  of  2 to  10  microseconds  will  occur  between  messages 
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FIGURE  10.  MULTIPLEXED  DATA  FLOW 
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Figure  11  shows  the  detail  interface  characteristics  of  the  AMUX 
data  link.  Each  set  of  data  lines  is  a twisted  shielded  pair 
cable  limited  in  length  to  300  feet  and  terminated  at  each  end 
with  a reactive  termination  network  composed  of  a resistor,  equal 
to  the  characteristic  impedance  of  the  line,  in  series  with  a 
capacitor  which  compensates  for  the  inadequate  low  frequency 
response  of  the  overall  network.  Up  to  31  interconnections,  or 
stubs,  are  connected  to  each  of  the  data  links  for  the  purpose  of 
interfacing  subsystems  with  the  Avionics  Control  Unit  Complex. 


FIGURE  11.  AMUX  LINE/STUB  INTERFACE 


One  of  the  significant  features  of  Boeing's  AMUX  system  is  that 
all  stubs  are  directly  spliced  to  the  data  link,  eliminating 
the  need  for  data  link  couplers  and  significantly  reducing  mainte- 
nance, logistic  and  on-board  fault  isolation  requirements.  The 
only  restrictions  this  interconnect  feature  imposes  on  harnessing 
requirements  is  that  (1)  accumulative  stub  lengths  over  any  50 
feet  of  data  link  must  be  less  than  100  feet,  and  (2)  total  accu- 
mulative stub  lengths  must  be  less  than  200  feet.  A maximum  of 
31  stubs  may  be  connected  and  stub  lengths  may  be  as  long  as  25 
feet.  An  extensive  amount  of  mock-up,  integration  and  flight 
testing  in  addition  to  detailed  transmission  line  analysis  and 
computer  simulation,  has  confirmed  this  transmission  line 
configuration. 
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I/O  Modem 


Boeing  was  able  to  achieve  a high  degree  of  commonality  by  imple- 
menting an  identical  circuit  design  for  the  interface  with  the 
AMUX  data  link.  This  design  is  referred  to  as  the  I/O  Modem.  By 
maintaining  a common  design  for  all  the  AMUX  interface  points  it 
was  possible  to  significantly  reduce  the  hardware  design  risks 
and  life  cycle  costs  of  the  Avionics  System.  Thirty-three  equip- 
ment items  interface  with  the  AMUX  channels,  19  of  which  are  built 
by  Boeing.  All  19  of  the  Boeing  equipment  items  contain  the  same 
I/O  Modem  circuit  design.  Three  printed  circuit  boards  are 
required  for  each  equipment  installation,  two  of  one  configuration 
and  one  of  another.  Less  than  ninety  dual-in-line  TTL  components 
were  utilized  in  this  design. 

The  basic  design  of  the  I/O  Modem  is  composed  of  coupling  trans- 
formers, receivers,  transmitters,  input  and  output  data  converters, 
diagnostic  circuitry  and  miscellaneous  timing  and  control  circuitry 
as  shown  in  Figure  12.  A significant  feature  of  the  I/O  Modem 
is  that  data  transfer  to  the  using  system  is  bit  serial.  This 
data  transfer  technique  significantly  reduces  Modem/subsystem 
interface  control  signals,  printed  circuit  board  interconnect 
pins  and  overall  logic  circuitry. 


FIGURE  12.  I/O  MODEM 
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Each  channel  of  the  I/O  Modem  design  continuously  monitors  the 
data  link  for  incoming  data.  When  the  data  is  detected  it  is 
transferred  by  the  coupling  transformer  from  the  line  to  the  input 
filter  of  the  receiver  for  conditioning  and  bandlimiting . The  bi- 
phase detector  monitors  the  output  of  the  receiver  for  edge  tran- 
sitions which  drive  the  I/O  programmer  for  all  timing  and  control 
functions.  The  address  comparator  compares  the  incoming  address 
of  all  Command  Words  with  the  hardwired  address  from  the  using 
subsystem.  When  the  Address  compares,  the  RIP  (reception  in 
progress)  discrete  is  activated  which  switches  the  channel  select 
and  I/O  control  select  to  the  active  channel.  The  interface  con- 
trol signals  then  coordinate  transfer  of  the  remainder  of  the 
message  to  the  using  subsystem  for  control  and/or  data  distribution. 
If  the  address  does  not  compare,  no  further  action  is  taken  and 
the  interface  signals  remain  inactive.  If  one  channel  receives 
a valid  command  word  with  the  correct  address  while  the  other 
channel  is  in  operation,  the  I/O  Modem  switches  from  the  latter 
channel  and  acknowledges  the  new  command. 

The  detection  and  generation  circuits  identify  each  word  sync 
and  carry  out  the  error  (ER)  diagnostic  checks  on  the  incoming 
data.  SDO  (serial  data  out),  the  output  of  the  NRZ  converter, 
is  sequentially  shifted,  bit  serial,  for  each  gated  clock  pulse 
(GCLK)  . 

The  using  subsystem  responds  to  a command  word  to  transmit  by 
raising  the  XMIT  (transmit)  discrete  after  the  fall  of  RIP  and 
sequentially  shifting  data  on  SDI  (serial  data  in)  for  each  GLCK 
pulse  provided  by  the  I/O  Modem.  The  bi-phase  encoder  compiles 
the  sync  and  parity  signals, derived  from  the  detection  and  genera- 
tion circuitry , with  SDI  and  converts  the  results  into  a modified 
Manchester  composite.  The  transmitter  buffers  the  output  of  the 
bi-phase  encoder  and  drives  the  primary  of  the  coupling  trans- 
former to  transfer  the  Manchester  coded  data  onto  the  data  link. 

Boeing' s design  approach  for  the  I/O  Modem  offers  a number  of 
significant  features  not  normally  provided  by  similar  designs. 

For  example,  an  ACU  can  implement  a data  transfer  interrupt,  to 
accommodate  higher  priority  requirements,  by  sending  a second 
command  word  down  the  redundant  data  link  to  the  alternate 
channel  of  a previously  activated  I/O  Modem  to  terminate  that 
Modem's  data  transfer  activities.  The  ACU  could  then  proceed 
with  the  higher  priority  data  transfer  to  either  the  same  sub- 
system or  any  other  interfacing  subsystem. 

Another  feature  of  this  design  approach  is  the  capability  to 
virtually  double  the  data  capacity  of  the  dual  redundant  inter- 
face lines  to  all  subsystems.  This  is  accomplished  by  programm- 
ing the  ACU  software  to  perform  scheduled  I/O  on  both  the  prime 
and  alternate  data  links  simultaneously  but  to  different  sub- 
system LRU  addresses.  In  this  fashion,  twice  as  many  subsystems 
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can  be  handled  in  a given  minor  frame  and  each  subsystem  still 
has  redundant  interfaces  that  provides  for  backup  retry  communi- 
cation capability  when  required. 

Growth 

An  example  of  the  flexibility  of  this  system  for  growth  was 
recently  demonstrated  with  the  implementation  of  the  Defensive 
Management  System,  a rather  extensive  electronics  subsystem 
involving  an  additional  ACU,  two  additional  video  display  genera- 
tors, and  three  additional  C & D panels,  which  was  authorized 
after  the  Offensive  Avionics  had  been  developed  and  deployed. 

This  system  is  shown  in  Figure  13  and  was  implemented  with  no 
change  to  existing  hardware  configurations  other  than  activation 
of  two  spare  ACU  AMUX  serial  data  ports,  minor  modifications  to 
an  existing  offensive  panel  (the  IKS)  to  make  it  compatible  for 
both  OSC  and  DSO  crew  stations,  and  implementation  of  the  remain- 
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ing  spare  parallel  channel  incorporated  into  the  MSU  for  defensive 
non-resident  core  storage.  However,  all  of  the  applicable 
Defensive  Controls  and  Displays  Subsystem  items  utilized  the 
already  developed  I/O  Modem  design  and  no  change  in  the  AMUX 
design  philosophy  was  required  in  integrating  this  weapon  sub- 
system with  the  existing  offensive  weapon  system. 


Summary 


Boeing  has  incorporated  the  greatest  amount  of  flexibility  and 
capability  into  the  B-l  AMUX  system  possible  consistent  with 
cost  effectiveness.  The  longevity  of  this  aircraft  and  its 
overall  effectiveness  in  America's  arsenal  of  airborne  hardware 
will  be  directly  dependent  upon  its  ability  to  accommodate  and 
adapt  to  ever  changing  and  increasingly  complex  navigation  and 
weapon  delivery  systems  as  they  become  operational. 


The  AMUX  multiplexing  system  employed  by  Boeing  in  integrating 
the  various  subsystems  of  the  B-l  Avionics  is  one  of  the  fore- 
runners of  avionics  multiplexing  and,  as  such,  has  been  relied 
upon  for  support  in  formulating  system  concepts  and  establishing 
performance  requirements  to  be  used  in  standardizing  interface 
specifications. 


This  system  has  been  shown  to  be  a powerful  data  management  and 
distribution  system  with  an  extensive  growth  capability  not  only 
for  adding  more  subsystems  on  line  but  increased  data  capaci- 
ty as  well.  As  a result,  the  B-l  Avionics  has  demonstrated  both 
the  need  and  value  of  standardizing  future  avionics  systems 
data  transfer  requirements  in  accordance  with  MIL-STD-1553 . 
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Harris  Electronic  Systems  Division  started  serious  experiments 
with  interior  data  bus  systems  in  1969.  This  included  analysis 
of  optimum  waveforms,  coding  and  parity  control  methods  for  the 
data  itself  and  various  methods  and  data  rates  for  transmission. 
Each  promising  data  format  and  transmission  method  was  rigorously 
tried  and  tested.  Experimentation  continued  throughout  the 
B-l,  Shuttle  and  Minuteman  programs  and  is  continuing  today  as 
part  of  the  ongoing  Harris  IR&D  in  data  bus  technology,  both  wire 
and  fiber  optic.  This  paper  addresses  some  of  the  major  con- 
clusions reached  in  wire  data  bus  systems  as  they  pertain  to 
MIL-STD- 1553 . 

Some  early  results  from  studies  which  hold  true  today  are  noted 
below: 

o A near  sinusoidal,  transmission  code,  such  as  Manchester 
coding,  has  the  best  propagation  characteristics, 
o Twisted  Shielded  Pair  Cable  offers  the  best  EMI  immunity 
in  the  1 MBPS  range  but  high  quality  cable  should  be  used, 
o The  same  basic  data  bus  techniques  developed  for  1 MBPS 
transmission  are  valid  through  5 MBPS, 
o Since  we  are  dealing  with  a "bucket  brigade"  carrying  data, 
actual  word  size  is  of  little  consequence  between  12  bits 
and  40  bits  for  average  mixes  of  data.  __ 

o Since  the  S/N  ratio  can  be  maintained  high  with  low  (10  or 
better)  bit  error  rates,  one  parity  bit  per  word  is  more 
than  sufficient  for  normal  bus  error  management, 
o A unique  word  sync  which  could  be  positively  acquired  was 
necessary  to  minimize  the  missed  message  rate.  A simple 
invalid  Manchester  code  which  could  be  decoded  in  under  3 
bit  times  was  the  answer. 

o We  were  dealing  with  band  limited  signals  at  between  .5 
and  1.5  the  bit  rate. 

o Simple  transmission  line  theory  matching,  reflections  VSWR, 
etc.  apply. 

The  design  resulting  from  this  early  development  was  very  similar 
in  concept  to  the  existing  MIL-STD-1553 . A demonstrator. 

Figure  1,  built  to  demonstrate  these  concepts  in  1970  contained  a 
balanced  twisted,  shielded  line;  terminated  in  its  characteristic 
impedance;  with  balanced  isolated  taps.  Bus  operation  was  half 
duplex  at  1 MBPS  and  3 separate  (triple  redundant)  lines  were 
demonstrated. 

The  biggest  mistake  turned  out  to  be  using  digital  designers  to 
solve  digital  transmission  problem.  The  entire  data  bus  is  a 
job  for  an  RF  design  engineer.  Without  such  an  approach  the 
system  is  ultimately  doomed  to  failure  or  at  best  marginal 
operation. 

As  we  begain  to  address  larger  systems  such  as  those  being  con- 
sidered for  B-l  and  Shuttle  applications  the  test  cable  lengths 
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increased  to  over  300  feet  with  32  stubs.  Although  these  trials 
verified  the  basic  design,  including  3 bit  time  sync  and  Man- 
chester coding,  two  "exciting"  facts  were  produced: 
o There  really  is  no  such  thing  as  a "dead  line"  (no  noise)  in 
a real  aircraft  environment.  This  means  that  if  the  sync 
code  depends  on  this  the  missed  message  rate  will  be  very 
high. 

o Without  very  sophisticated  receivers,  false  spikes  could  not 
be  eliminated  and  most  methods,  including  thresholding*, 
could  cost  dearly  in  missed  messages  of  failure  to  detect 
word  sync  at  low  signal  levels. 

Resulting  key  parameters  for  the  design  of  the  data  bus  for 
longer  transmission  lines  are  shown  in  Table  1 compared  to  the 
requirements  of  MIL-STD-1553.  Only  a few  differences  are  worthy 
of  mention: 

o The  experimental  data  word  contained  20  data  bits  rather  than 
16  of  the  MIL-STD-1553.  Since  large  amounts  of  discrete  data 
were  anticipated.  As  high  as  32  or  40  bits  per  word  were 
actually  considered  at  the  time  for  the  EMUX. 
o A unique  command  sync  was  reserved  only  for  commands. 

Whereas  MIL-STD-1553  allows  the  same  command  sync  for 
status  reply.  Failure  modes/effects  analysis  indicated  that 
restricting  command  sync  to  only  that  function  minimized 
the  possibility  of  a random  response  due  to  receiver  decoder 
failure. 

o The  bit  error  rate  was  set  with  a specific  S/N  ratio  at  the 
input  to  the  data  bus  receiver.  Whereas  MIL-STD-1553A 
specifies  a corrected  bit  error  rate  with  the  cable  in  the 
presence  of  electric  and  magnetic  fields  per  MIL-STD-461 
and  MIL-STD-462 . 

The  latter  point  is  worthy  of  consideration  for  the  future. 

Since  the  noise  that  is  actually  coupled  onto  the  data  bus  is 
totally  dependant  on  the  type  of  cable  and  the  maintainance  of 
continueous  shielding  through  out  the  installed  cable  length, 
the  burden  of  system  compatibility  due  to  noise  will  lie  with 
the  airframe  manufacturer  instead  of  MUX  supplier.  Consideration 
should  be  given  to  more  quantitive  measure  in  MIL-STD-1553. 
Further,  since  the  test  time  required  to  prove  the  10-12  cor- 
rected bit-error-rate  is  extensive,  it  may  be  impractical  to 
test.  The  solution  may  be  as  simple  as  extrapolating  the  pro- 
jected S/N  ratio  at  the  receiver  input  to  a smaller  number  that 
would /increase  the  theotitical  bit-error-rate  to  say  10”^  or  10“  . 

The  reason  for  concern  as  to  the  bit-error-rate  compliance  with 
MIL-STD-1553A  is  due  to  the  evaluation  of  sync  detection  and 
data  decoding  schemes.  As  was  mentioned  previsously  the  problem 
is  RF  in  nature  and  not  digital.  The  Manchester  encoding  is  no 
problem  for  any  digital  designer,  and  given  pure  encoded 
*Not  recognizing  incoming  signals  below  a selected  value. 
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A.  RECEIVER  REQUIREMENTS 


Original  Long 
Line  Criteria 

+3.6V  to  +1.35V 


Signal  Levels 
Data  Rate 
Word  Format 

Input  Impedance 
Bit  Error  Rate 

Message  Dismis- 
sal Rate 

Noise 

Conditions 


1553A 

+0.5V  to  +10. OV 

1 Mb/s  Manchester 

Sync:  3 bits 
invalid 
Manchester 
Data:  16  bits 
Parity:  1 bit 
(Odd) 

>2K  ohms  0.1  to 
1 MHz 

<10 12  (After 
message  valida- 
tion) 

<10* 


MIL-STD-462/ 
Method  RS03 
Electric  Field 
1 V/M  14  kHz- 
10  GHz 

MIL-STD-462, 
Method  RS-2 
Magnetic  Field 
Spike  100V,  10  ys 
into  5ft  3 turns/ 
1.5M  with  rep. 
rate  up  to  10  pps 
MIL-STD-461  Test 
Limit  RS02 


1 Mb/s  Manchester 

Sync:  3 bits 
invalid 
Manchester 
Data:  20  bits 
Parity  (Odd) : 

1 bit 

>2K  ohms  0.1  to 
1 MHz 

<10-7  (Prior  to 
word  validation) 


Random-White  Noise 
S/N=14  dB  in  a 
4 MHz  BW  with  +1.5V 
Signal 


TABLE  1 (Cont) 
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A. 

RECEIVER  REQUIREMENTS  (continued) 

Additional 

Noise 

Rejection 

Requirements 

Common  mode  signals 
£10  volts  peak  line 
to  ground  DC  to  2.0 
MHz  with  no  degra- 
ded performance 

Reject  all  noise  up 
to  +6  V peak  line 
to  Tine  below  1 kHz 
and  above  4 MHz 

Validation 

Requirements 

1.  Valid  sync 

2.  Valid  Man- 
chester data 

3.  Word  length 

4.  Parity 

(SAME) 

Additional 

Requirements 

At  operate  with 
sine  wave  or  square 
wave  signals  at 
receiver  input 

At  operate  with 
sine  wave  or  square 
wave  signals  at 
receiver  input 

B. 

TRANSMITTER 

REQUIREMENTS 

Output 

Voltage 

13+7  volts 
pea£  to  peak,  line 
to  line  under  load 
conditions 

2.7  to  7.2  volts 
peak  to  peak,  line 
to  line  at  loads 
(30  +3  V (peak-to- 
peakT  open  circuit 

Output  Noise 

<10  mV  peak  to  peak. 
Tine  to  line 

Output 

Waveform 

Zero  crossing 
deviations  <25ns 
rise  and  faTl 
times  £l00ns 

Rise  and  fall  times 
<100ns  and  <400ns 

C. 

CABLE  CHARACTERISTICS 

Type 

Twisted- shielded 
pair 

Twisted-shielded 

pair* 

♦Several  cable  types  were  tried  with  little  operating  difference 
noted. 
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C.  CABLE  CHARACTERIS 

TICS  (continued) 

Characteristic 

Impedance 

70  ohms  +10%  at 
1 MHz 

70  ohms  +10%  at 
1 MHz 

Cable 

Attenuation 

<1  dB/100  ft.  at 
T MHz 

Cable  Length 

<300  ft. 

<325  ft. 

Fault  Isolation 

Series  Resistors 
(0.75  Z0) 

Series  Resistors 
(0.75  Z0) 

Manchester  data  the  transmitter  is  reduced  to  a simple  push- 
pull  driver  with  a controlled  rise  and  fall  time  output. 

However,  the  decoding  scheme  is  another  problem  altogether. 

Common  erroneous  assumptions  made  by  the  designer,  particularly 
if  his  background  is  in  digital  world: 
o The  data  bus  is  either  active  or  dead 
o To  insure  a dead  line  increase  the  receiver  threshold 
o Sync  is  3.0 //  seconds  and  divided  into  two  equal  parts  of 

1.5//  seconds  each  ± some  small  percentage.  (Percentage  must 
be  small,  the  data  at  the  other  end  using  a crystal  clock  for 
reference. ) 

o Data  is  1.0//  seconds  and  the  transition  is  always  at  mid 
bit  ± some  small  percentage 

So  you  design  a decode  scheme  around  these  assumptions.  It  gets 
"analyzed"  and  OK'd.  It  gets  bread  boarded,  and  you  test  it 
over  only  about  20  feet  of  cable  because  300  feet  with  32  stubs 
just  isn't  available.  And  it  works,  fantastic.  So  you  build  a 
system  around  it.  Now  the  trouble  really  starts.  You  finally 
get  the  full  300  feet  and  about  20  stubs  hooked  up.  You  ins- 
tall the  Bus  Controller  and  Remote  Terminal  at  each  end,  add  a 
little  noise  and  you  get  garbage  out. 

The  data  bus  wave  form  at  the  remote  terminal  is  not  the  pure 
wave  form  you  saw  at  20  feet.  Its  distorted,  the  pulse  widths 
vary  ± 30%,  and  due  to  the  noise  there  is  no  dead  line. 

Raising  the  receiver  threshold  solves  the  dead  line  problem  but 
at  300  feet  the  signal  is  almost  always  below  the  new  threshold 
so  your  missed  message  rate  increases  beyond  bounds.  Figure  2 
shows  a curve  of  threshold  vs.  Gaussian  noise  for  a typical 
Manchester  coded  signal  with  a value  of  slightly  under  ± 3V. 

The  optimum  threshold  is  amazingly  low. 

Consultation  with  a good  RF  designer  reveals  that  the  wave 
form  on  the  bus  is  exactly  what  is  to  be  expected,  and  you 
should  have  followed  these  ground  rules  instead: 
o In  actual  system  operation  with  cable  length  upwards  of  150 
feet  and  normal  aircraft  environment,  there  will  be  no  such 
thing  as  a dead  line  unless  the  receive  threshold  is  raised 
and  the  corresponding  increase  is  Missed-Message-Rate  can  be 
tolerated  with  the  system.  Therefore,  base  your  sync  det- 
ection scheme  on  the  presence  of  data  not  the  absence, 
o Since  the  signal  widths  vary  due  to  amplitude  modulation  and 
noise  you  must  base  the  decoder  sampling  on  a point  in  the 
waveform  which  has  the  highest  probability  of  being  true  state. 
This  point  can  be  selected  cased  on  the  sync  signal  and 
sampling  windows  can  be  predetermined  for  the  entire  word 
length . 
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RECEIVER  THRESHOLD 


Rations  for  BER  Versus  Threshold 


These  new  ground  rules  led  us  to  our  present  design  technique 
which  is  implemented  in  recent  programs. 

Design  improvements  through  a continuing  IR&D  program  at  Harris 
has  enchanced  this  technique  and  produced  a significantly  simpler 
model  using  an  LSI  encoder/decoder  chip  to  perform  the  Manchester 
conversion,  sync  detection,  and  word  validation. 

The  new  LSI  MTU  module  is  designed  to  not  only  provide  MIL-STD- 
1553A  interface  compatibility  but  to  operate  with  any  Manchester 
coded  data  bus  of  10  MHz  or  less  and  of  word  lengths  up  to  32 
bits . 

Figure  3 is  a simple  block  diagram  of  the  functions  sjjithin  this 
module.  A 

+15  V -15  V +5  V 


MANCHESTER 
CODED 
DATA  BUS 
STUB 
PER  MIL-STD- 
1553 A 


.!*■(  0*T* 

0»COOI«  JHilT  ClOC« 


♦ *OMOCOU«r 

su**on«(M'vnn<  coot 


SUBSYSTEM 
INTERFACE 
TTL  LOGIC 
COMPATIBLE 


Figure  3 MTU  Block  Diagram 

All  Manchester  coding,  decoding,  and  receiver  detection  is  per- 
formed in  a single  silicon  on  sapphire  LSI  chip.  The  trans- 
mitter, receiver,  and  oscillator  are  still  discrete  components. 

The  modules  provide  all  of  the  interface  timing  and  control 
functions  required  for  MIL-STD-1553A  and  has  selectable  flexi- 
bility for  other  formats.  Key  functions  performed  are: 

Transmit  Cycle  Functions 

(Upon  receipt  of  transmit  enable  command  from  subsystem  unit) 

o Generates  all  timing  required  for  TTL  data  transfer  from  the 
suosystem. 

o Accepts  Serial  MR7.  TTL  data  from  subsystem  unit. 
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o Generates  word  sync  pattern, 
o Encodes  NRZ  data  to  Manchester  format, 
o Generates  word  parity. 

o Transmits  formatted  word  onto  data  bus  via  balanced  band- 
limited  data  bus  transmitter. 

Receive  Cycle  Functions 

o Monitors  and  filters  the  input  from  the  data  bus  via  a balanced 
data  bus  receiver, 
o Performs  sync  detection 

o Distinguishes  between  command  and  data  sync, 
o Decodes  Manchester  data  into  NRZ. 

o Generates  all  timing  required  for  data  transfer  to  the 
subsystem, 
o Word  validation 

- Tests  for  valid  sync  field 

- Tests  for  valid  Manchester  code  on  each  bit 

- Tests  for  word  length 

- Tests  for  valid  word  parity 
o Detects  address 

o Contains  holding  register  for  command  word 


Power 

Requirements 

Transmit  Cycle 

Receive 

+15  V ±10% 

2W 

0.5W 

-15  V ±10% 

2W 

0.5W 

+5  V ±10% 

1.5W 

1.5W 

S . 5W 

2.5W 

Flexibility 

Functions  which  are  electrically  selectable  by  jumper  or 
variable  electrical  inputs  from  the  parent  unit  include: 

o Variable  Word  Length  - up  to  32  bits;  word  length  selection 
via  5-pin  code  plug.  (16  bits;  MXL-STD-1553A) 
o Parity  - odd  or  even  parity;  independent  transmit  and  receive 
parity  control  via  input  select  pins 

Custom  Capabilities 

Custom  MTU  capabilities  can  be  provided  to  accommodate  special 
environments,  intsallation,  and  subsystem  operational  require- 
ments such  as: 

o Full-  or  Half-Duplex  Operation  - complete  independent 
operation  of  the  transmit  and  receive  functions  allows 
both  full-  and  half-duplex  operation 
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Special  Interface  Requirements  - can  be  provided  with  logic 
to  accommodate  specific  system  requirements  as: 

- Buffer  memory  for  message  storage 

- Independent  status  register 

- Interface  circuits  for  different  logic  families#  etc. 
Special  Speed  Requirements  - LSI  configuration  can  accomo- 
date data  bus  rates  up  to  10  MHz 
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ABSTRACT 


The  Space  Shuttle  multiplex  data  bus  network  inter- 
connects the  Orbiter  central  processors  to  the  vehicle 
flight  control,  launch,  orbital  maneuvering,  systems  and 
payload  management,  instrumentation,  and  other  subsystems 
for  acquisition  of  subsystem  data  and  for  transfer  of 
commands.  Avionics  elements  are  interfaced  to  the  data 
bus  network  by  a single-design,  standard  interface  module 
that  provides  transmitter/receiver  and  encoder/decoder 
functions.  Functional  partitioning,  control  and  data 
transfer  methods,  error  detection  and  handling,  and  the 
physical  and  electrical  characteristics  of  the  data  bus 
system  as  they  apply  to  the  Space  Shuttle  are  discussed. 
Also  considered  are  the  implementation  and  design 
problems  encountered  in  the  integration  of  the  data  bus 
design  approach  into  the  Space  Shuttle  avionics  system 
elements . 


INTRODUCTION 


The  Space  Shuttle  avionics  system  elements  are 
controlled  by  a five-computer  data  processing  system  to 
which  they  are  connected  by  a network  of  multiplex  data 
buses.  This  data  bus  network  extends  into  the  Orbiter 
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avionics  and  payload  bays  and  the  solid  rocket  boosters  to 
implement  a highly  integrated  control  system  for  all  Shuttle 
launch,  aerof light,  orbital  maneuvering  and  landing  functions; 
systems  and  payload  management;  and  instrumentation.  The 
data  bus  network  provides  the  communications  medium  for  the 
acquisition  of  subsystem  data  and  for  the  transfer  of  commands 
from  the  central  processors  to  the  vehicle  effector  subsystems. 

With  respect  to  data  bus  applications,  the  Space  Shuttle 
will  represent  the  first  operational  flight  vehicle  to  use 
a digital  data  bus  flight-control  system  mechanization.  In 
this  mechanization,  all  sensor  data  and  effector  commands 
for  both  primary  and  backup  systems  are  transmitted  over  a 
serial  data  bus  network.  This  is  also  the  first  large  data 
bus  system  in  which  all  avionics  hardware  that  interfaces 
with  the  data  bus  network  utilizes  a single-design  data  bus 
transceiver.  In  the  Space  Shuttle,  10  different  avionics 
hardware  items  supplied  by  8 companies  use  the  multiplexer 
interface  adapter  (MIA)  modules  developed  by  Singer- 
Kearfott  Division  and  supplied  as  buyer-furnished  equipment 
by  Rockwell  International,  Space  Division,  the  prime 
contractor  for  the  integration  of  the  Orbiter  and  the 
Shuttle. 

This  paper  concerns  the  role  of  the  data  bus  in  the 
Shuttle  avionics  system;  the  functional  and  operational 
characteristics  of  the  multiplex  data  bus  system;  the  mana- 
gerial, developmental,  verification,  and  integration 
approaches  to  system  implementation;  and  the  problems 
encountered  and  the  lessons  learned  during  system  devel- 
opment. Discussion  of  the  data  bus  element  characteristics 
is  limited  to  the  data  bus  controllers  (input/output 
processors) , developed  by  IBM;  the  data  bus  network 
elements,  developed  by  Singer-Kearfott  Division;  and  the 
multiplexer/demultiplexer  units,  developed  by  Sperry- 
Flight  Systems,  a division  of  the  Sperry  Rand  Corporation. 


AVIONICS  SYSTEM/DATA  BUS  NETWORK  RELATIONSHIPS 


The  multiplex  data  bus  system  interconnects  the  Space 
Shuttle  avionics  hardware  as  illustrated  in  Figure  1.  Each 
of  the  five  input/output  processor  (IOP)  units  is  connected 
to,  and  has  the  ability  to  communicate  with,  other  IOP's, 
data  processing  peripheral  hardware,  and  the  vehicle 
subsystems  over  24  data  buses.  Each  IOP  provides  the 
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associated  central  processor  unit  (CPU)  with  the  capability 
to  control  or  listen  to  any  combination  of  the  24  data 
buses.  The  controller  for  each  data  bus  is  determined  by 
the  multicomputer  software  executive.  The  Space  Shuttle 
subsystems  are  connected  to  the  data  buses  by  multiplexer/ 
demultiplexer  (MDM)  units  and  other  bus  terminal  units. 

The  MDM 1 s interface  the  majority  of  the  Space  Shuttle 
subsystems  with  the  data  bus  network.  They  provide  for 
the  acquisition  of  subsystem  data  under  CPU  control  and 
route  CPU-generated  commands  to  the  selected  user  subsystems. 
The  other  bus  terminal  units,  which  include  the  engine 
interface  unit  (EIU) , the  display  driver  unit  (DDU) , the 
master  events  controller  (MEC) , the  display  electronics 
unit  (DEU) , the  manipulator  controller  interface  unit  (MCIU) , 
and  the  pulse  code  modulation  (PCM)  master  units,  provide 
for  special  subsystem  interface  requirements  that  the  MDM's 
are  not  equipped  to  handle.  The  EIU's  provide  specially 
formatted  serial  commands  to  the  Space  Shuttle  main  engines. 
The  DDU's  condition  computer  commands  for  direct  control  of 
the  analog  flight  displays.  The  MEC's  provide  special 
timing  and  lockout  circuits  for  computer-controlled  firing 
of  the  pyrotechnics.  The  DEU's  interface  the  keyboard  data 
entry  and  cathode  ray  tube  (CRT)  display  units  to  the  data 
buses.  The  MCIU  provides  for  computer  control  of  the 
payload  manipulator  arm.  The  PCM  master  units  acquire  and 
format  vehicle  instrumentation  for  storage,  downlink,  and 
access  by  the  CPU's. 

The  data  bus  network  configuration  is  designed  to 
satisfy  vehicle  redundancy  and  computer  software  parti- 
tioning requirements.  In  accordance  with  subsystem  redun- 
dancy requirements,  the  data  buses  are  arranged  to  provide 
multiple  data  paths  to  the  CPU's.  Multiple  bus  terminal 
units  are  used  as  required  to  support  the  redundant  data- 
path requirements.  In  addition,  each  bus  terminal  unit 
(BTU)  connects  to  one  or  more  data  buses  as  necessary  to 
satisfy  system  redundancy  requirements.  The  EIU's  and 
the  MEC's,  for  example,  interface  with  four  data  buses,  and 
all  the  MDM's  interface  with  two  data  buses.  Software 
partitioning  requirements  are  satisfied  by  grouping  the  data 
buses  into  functional  sets.  The  eight  flight-critical 
buses  interface  with  the  aerof light,  orbital,  and  landing 
subsystems.  Four  of  these  data  buses  interface  with  flight 
control  hardware  in  the  forward  part  of  the  Orbiter  vehicle, 
and  the  other  four  buses  interface  with  the  flight  control 
hardware  in  the  aft  area..  Five  data  buses  are  dedicated 
to  intercomputer  data  transfers.  The  two  mass  memory 
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systems,  the  four  DEU's  and  associated  keyboards  and  CRT 
displays,  and  the  two  PCM  master  units  are  connected  to  the 
five  CPU/IOP ' s by  dedicated  data  buses.  Two  mission- 
critical  data  buses  interface  with  the  payload  bay  doors 
and  the  caution  and  warning  subsystem.  These  buses  also 
provide  the  primary  interface  between  the  vehicle  computers 
and  the  payload  subsystems.  For  Shuttle  checkout  and 
prelaunch  operations,  the  two  ground-interface  data  buses 
provide  the  launch  processing/ground  support  equipment  (GSE) 
with  direct  access  to  the  CPU/IOP' s,  the  payload  manipu- 
lator, and  the  two  solid  rocket  boosters.  Two  additional 
instrumentation  data  buses  controlled  by  the  PCM  master 
units  provide  for  the  acquisition  of  operational  instru- 
mentation data.  The  Orbi ter/solid  rocket  booster  (SRB) 
and  the  Orbiter/GSE  data  bus  interfaces  utilize  a data 
bus  isolation  amplifier  (DBIA)  that  functions  as  a line 
driver/repeater.  After  Orbiter/SRB  separation,  the  DBIA 
prevents  noise  on  the  severed  SRB  data  buses  from  affecting 
the  associated  Orbiter  buses. 


DATA  BUS  SYSTEM  CHARACTERISTICS 


All  data  flow  is  processed  at  1 megabit/sec  in  a half- 
duplex manner  with  fixed  word  lengths  and  flexible  message- 
length  transfers.  Data  are  transferred  on  the  data  buses 
in  a demand/response  mode.  Each  data  transmission  is 
initiated  by  an  IOP-generated  command  word,  and  the  BTU 
data  responses  can  be  monitored  by  any  or  all  IOP's.  Data 
transfers  to  BTU's  are  initiated  by  a command  word  followed 
by  as  many  as  512  command  data  words.  Data  transfers  from 
BTU's  are  in  response  to  an  IOP-transmitted  command  word 
and  contain  blocks  consisting  of  1 to  512  data  words. 

Operationally,  avionics  software  designates  which  of 
the  five  CPU/IOP 's  will  act  as  the  controller  for  each  of 
the  network  data  buses.  Each  terminal  on  the  bus  maintains 
an  independent  clock  for  data  transmission  and  reception 
on  the  bus. 

Word  formats  are  illustrated  in  Figure  2.  Command 
words  consist  of  word  synchronization  pattern,  BTU  address, 
a 19-bit  instruction  field,  and  parity.  The  instruction 
field  contains  mode  information  and  other  data  that 
identify  the  type  of  BTU  action  requested  by  the  CPU/IOP. 
The  command  data  word  consists  of  an  inverted  word 
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COMMAND  WORD 


synchronization  pattern,  BTU  address,  16  bits  of  data,  a 
fixed  101  pattern,  and  parity.  The  response  data  word 
format  is  identical  with  the  command  data  word  format 
except  that  3 bits  of  BTU  status  data  replaces  the  101 
pattern.  The  number  of  words  transmitted  in  a message  is 
controlled  by  the  CPU/IOP  by  means  of  the  command  word 
instruction  field.  A 5-  to  6-microsecond  gap  time  exists 
between  successive  words  in  a message.  The  information  is 
encoded  in  a bipolar  Manchester  II  form  in  which  each  bit 
consists  of  a pulse  of  one  polarity  followed  by  a pulse  of 
the  opposite  polarity.  The  line  is  unenergized  between 
words. 


The  data  bus  design  incorporates  an  error-detection 
capability  to  preclude  the  use  of  erroneous  data  by  the 
CPU/IOP  or  any  other  BTU.  In  addition  to  BTU  address 
recognition  and  interword  gap  time  and  message  lengths 
that  are  checked  by  the  receiving  BTU,  the  MIA  modules 
evaluate  signal  quality  and  provide  error  flags  to  the 
host  BTU  when  errors  are  detected  in  the  received  message. 
Four  independent  error-detection  checks  are  continuously 
used  by  the  MIA's: 

1.  Detection  of  a unique  bipolar  synchronization 
pattern  to  initiate  each  word 

2.  Detection  of  the  bipolar  Manchester  waveform  for 
each  bit  in  the  word 

3.  Detection  of  the  minimum  number  of  bits  required 
in  each  word 

4 . Detection  of  odd  parity  for  each  word 

Received  data  words  that  fail  any  of  these  error-detection 
checks  are  discarded  by  the  BTU.  Scheduled  (periodic) 
data  updating  and  the  use  of  redundant  data  paths  allow  the 
avionics  system  to  accommodate  random  data  losses. 

. -7 

The  system  error-rate  requirement  is  3 x 10  , as  a 

ratio  of  erroneous  words  to  the  total  number  of  words 
transmitted.  The  error-rate  requirement  was  originally 
specified  as  a bit  error  rate,  which  was  found  to  be  an 
inadequate  performance  indicator.  This  specification,  as 
applied  to  the  MIA,  must  be  met  with  a signal  level  of 
1.5  Volts  peak  in  the  presence  of  300-millivolt  root  mean 
square  (rms)  white  Gaussian  noise  distributed  over  the 
band  of  1.0  kilohertz  to  4.0  megahertz. 
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Signal  levels  on  the  data  bus  cables  are  designed  to 
provide  a sufficient  signal-to-noise  margin  so  that  error 
rates  are  within  acceptance  limits.  The  voltages  are 
typically  13  volts  peak,  line  to  line  on  the  transmitting 
stub;  5 volts  peak,  line  to  line  on  the  data  bus;  and  3 
volts  peak,  line  to  line  on  the  receiving  stub. 

A typical  data  bus  configuration  as  used  in  the  Space 
Shuttle  is  depicted  in  Figure  3.  The  bus  has  no  branches 
and  each  end  is  terminated  in  the  characteristic  impedance 
Zq  of  the  cable.  All  interconnections  to  the  data  bus 

are  made  through  transformer-coupled  stubs.  These  trans- 
formers and  the  terminating  resistors  used  on  the  ends  of 
the  bus  are  physically  mounted  in  very  small  (1  by  1 by  1 
inch)  boxes  known  as  data  bus  couplers.  The  stub  end  is 
normally  terminated  with  the  high  impedance  of  the  MIA 
(6000  0 in  parallel  with  60  picofarads)  in  the  receive 
mode.  When  transmitting,  the  MIA  presents  a low  (<10  fi) 
impedance  to  the  stub.  To  minimize  reflections,  the  trans- 
former impedance  matching  at  the  stub/bus  interface  reflects 
Zq  to  the  stub.  The  same  type  of  twisted,  shielded  pair 

cable  is  used  for  both  the  bus  and  the  stubs.  This  cable 
has  a nominal  characteristic  impedance  of  78  0,  a line-to- 
line  capacitance  C of  22  pF/ft,  and  an  attenuation  of 
1.2  dB/100  ft. 

The  data  bus  length  limitation  is  350  feet.  A 
maximum  of  20  stubs  is  permitted,  each  having  a maximum 
length  of  23  feet.  The  bus  system  has  the  capability  of 
sustaining  at  least  one  shorted  stub  condition  and  main- 
taining communications  with  the  remaining  stubs  on  the 
same  bus.  Under  these  conditions,  some  error-rate 
performance  degradation  is  normally  experienced.  This 
system  requirement  is  met  by  inserting  current-limiting 
resistors  in  series  with  the  transformer  in  the  data  bus 
coupler  (DBC) . These  resistors  are  on  the  data  bus  side 
of  the  transformer  and  are  physically  a part  of  the  DBC. 


DATA  BUS  SYSTEM  ELEMENT  CHARACTERISTICS 


This  section  includes  brief  descriptions  of  the  MIA 
module,  the  IOP,  and  the  MDM.  Additional  discussion  of 
these  key  data  bus  system  elements  will  increase  the 
understanding  of  the  overall  data  bus  operation. 


FT  MAX . 


Figure  3.-  Data  tus  configuration 


MIA  Description 

The  MIA  serves  as  a common  transceiver  module  in  each 
BTU  requiring  a data  bus  interface.  The  two  basic 
functions  of  the  MIA  are  to  (1)  encode  nonreturn-to-zero 
(NRZ)  data  to  Manchester  form  and  transmit  that  waveform 
onto  the  data  bus,  and  (2)  decode  the  Manchester  signals 
on  the  data  bus  to  the  NRZ  form  for  the  host  unit.  The 
MIA  generates  a synchronization  pattern  to  initiate  each 
word  transmission  and  provides  flags  to  the  BTU  indicating 
received  data  errors.  In  addition  to  the  receiver  error- 
detection  features  described  in  the  previous  section,  the 
MIA  generates  the  parity  bit  for  each  transmitted  word. 

Two  different  versions  of  the  MIA  have  been  produced; 
one  for  general-purpose  use  and  the  other  (containing 
special  host  interfaces  and  packaging)  for  the  computer  IOP. 

A block  diagram  of  the  MIA  is  shown  in  Figure  4.  The 
MIA  incorporates  a single  transformer  to  provide  the 
interface  to  the  data  bus  stub.  This  transformer  is  used 
for  both  transmission  and  reception  by  means  of  separate 
windings  on  the  MIA  side.  The  transmitter  and  receiver 
functions  were  both  implemented  within  a single  hybrid 
circuit  using  transistor-transistor  logic  (TTL)  and  discrete 
components.  The  receiver  decoding  function  and  some  of  the 
transmitter  encoding  circuitry  were  implemented  in  a 
complementary  metal-oxide  semiconductor,  large-scale 
integrated  circuit  package.  The  timing  and  control  functions 
and  the  remainder  of  the  encoding  logic  were  implemented  in 
another  TTL  hybrid,  whereas  the  buffers  providing  the  host 
interface  utilize  standard  TTL  integrated  circuits. 

The  various  MIA  interfaces  with  the  host  BTU  are 
critical  to  overall  communications  reliability.  The  NRZ 
data  interfaces  were  mechanized  serially  with  several  "hand- 
shaking" signals  provided  to  control  synchronization.  The 
host  unit  provides  the  MIA  with  a high-frequency  clock  (16 
megahertz)  from  which  other  required  clocks  are  derived  in 
addition  to  the  necessary  supply  voltages.  The  host  unit 
must  also  provide  a heat  sink  mounting  for  the  MIA  because 
a significant  heat  load  is  generated  during  transmission. 

The  MIA  is  fabricated  on  a small  card  that  is  usually 
mounted  to  a mother  card  by  the  manufacturer  of  the  host 
unit.  The  electrical  connections  are  made  by  a special 
pin-out  connector  on  the  MIA  that  is  normally  mated  with 
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Figure  4.-  MIA  block  diagram 


printed  circuit  mounting  holes  in  the  mother  card  and 
soldered  in  place.  The  MIA  dimensions  are  2.5  by  4.75  by 
0.4  inches,  and  the  weight  is  0.3  pound.  Maximum  power 
consumption  ranges  from  3.3  watts  in  the  receive  mode  to 
7.4  watts  in  the  transmit  mode. 


Input/Output  Processor 

One  of  the  more  important  host  BTU's  for  the  MIA  is 
the  IOP.  This  unit  provides  the  required  data  bus  control 
functions  for  its  associated  CPU.  Basically,  the  IOP  is  a 
microprogramed,  time-shared  processor  with  an  instruction 
set  that  services  the  24  MIA  channels  and  controls  the 
transmission  and  reception  of  data  semiautonomously  after 
initialization  by  the  CPU. 

As  illustrated  in  Figure  5,  the  IOP  is  essentially  a 
single  processor  with  a time-multiplexed  interface  to  the 
24  MIA  data  bus  channels.  Each  MIA  and  the  associated 
buffer  register  are  serviced  in  a fixed  sequence  that 
permits  simultaneous  data  transfers  over  the  24  data  buses. 
The  servicing  of  all  24  MIA  channels  every  16.5  microseconds 
provides  ample  time  for  the  IOP  to  process  the  reception  or 
transmission  of  a data  bus  word  every  33  microseconds  (28- 
bit  word  plus  interword  gap  time) . Other  data  bus  process- 
ing performed  by  the  IOP  includes  timeout  of  BTU  responses 
to  IOP  data  requests,  monitoring  interword  gap  time  on 
received  messages,  checking  response  messages  for  proper 
BTU  address  and  status  codes,  and  logging  all  MIA-  and  IOP- 
detected  data-transf er  errors  in  a status  register  for  CPU 
access. 

The  CPU/IOP  communication  is  provided  by  both  a 
program-controlled  input/output  (PCI/PCO)  and  a direct 
memory  access.  The  program  control  interface  is  used  for 
IOP  initialization,  MIA  transmit  and  receive  enable/inhibit 
control,  initialization  of  IOP/data  bus  transfers,  and 
transfer  of  IOP  status  data  and  data  bus  error  status  to 
the  CPU.  Direct  memory  access  is  used  to  acquire  data  from 
the  CPU  memory  for  transmission  onto  the  data  buses  and  to 
store  received  data  bus  messages  in  the  CPU  memory. 


Other  key  features  of  the  IOP  include  data  bus 
monitoring  (listening)  implementation,  redundancy  management, 
and  built-in  test.  Listening  is  a feature  that  permits  an 
IOP  to  input  BTU  response  data  from  a data  bus  channel  that 
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Figure  5 •**  Input/output  processor  block  diagram. 


is  being  controlled  by  another  IOP.  A special  setup 
command  word  is  sent  by  the  controlling  IOP  to  the  listening 
IOP's  before  the  acquisition  command  is  transmitted  to 
the  BTU.  Both  the  controlling  IOP  and  the  listening  IOP's 
then  receive  the  requested  data  simultaneously.  Identical 
data  are  thus  available  to  the  CPU's  for  redundant  compu- 
tations without  additional  intercomputer  communication 
links.  Redundancy  management  of  the  multiple  CPU/IOP  sets 
is  accomplished  by  a data  exchange/compare  technique.  Each 
IOP  periodically  accepts  a message  from  the  other  IOP's  that 
contains  a status  word  reflecting  the  result  of  selected 
CPU  computations.  The  IOP  compares  the  received  data  with 
its  own  CPU's  status  word  and  derives  an  opinion  on  the 
status  of  the  other  CPU/IOP' s.  The  opinions  of  each  IOP 
are  subsequently  presented  to  the  crew  by  a matrix  display. 
The  IOP  built-in  test  includes  oscillator  failure,  micro- 
code parity,  and  other  parameter  checks  normally  found  in 
state-of-the-art  computational  hardware. 


Mu It iplexer/Demul t iplexer 

The  Space  Shuttle  contains  24  MDM  units:  20  in  the 
Orbiter  avionics  system  and  2 in  each  of  the  2 SRB's.  In 
addition,  the  early  Orbiter  vehicles  will  carry  one  extra 
MDM  as  part  of  a backup  flight  control  system  and  from 
three  to  six  MDM's  in  a development  flight  instrumentation 
subsystem. 

The  MDM  interfaces  the  vehicle  sensor,  effector,  and 
instrumentation  subsystems  to  the  data  bus  and  acts  as  a 
data  acquisition,  distribution,  and  signal-conditioning 
unit.  In  response  to  commands  received  from  the  data  bus 
that  contain  their  assigned  address,  the  MDM's  condition 
and  route  received  data  to  the  specified  subsystem  inter- 
face; sample,  condition,  and  encode  specified  subsystem 
signals;  and  transmit  acquired  data  onto  the  data  bus. 

As  illustrated  in  Figure  6,  the  MDM  consists  of 
redundant  MIA's,  control  circuitry  and  power  supplies, 
and  as  many  as  16  input/output  modules.  The  MDM  is 
designed  so  that  both  redundant  sections  can  access  all 
16  input/output  modules;  simultaneous  operation,  however, 
is  precluded  by  MDM  design.  Nine  input/output  module 
( IOM)  types  are  provided,  and  the  IOM  complement  for  any 
given  MDM  is  dependent  on  interfacing  subsystem  require- 
ments. There  are  nine  MDM  types  now  on  the  Space  Shuttle. 
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Eight  of  the  MDM  types  are  used  in  the  Orbiter  and  are 
essentially  identical  except  for  IOM  configurations.  The 
ninth  MDM  type  is  used  in  the  SRB's.  This  type  MDM 
contains  8 instead  of  16  IOM's,  and  environmental  require- 
ments necessitated  a different  package  design.  The  MDM 
IOM  types  include  5-volt  and  28-volt  discrete  IOM's,  +5- 
volt  analog  IOM's,  serial  data  IOM's,  and  a special  module 
to  interface  the  Orbiter  Tacan  with  the  radar  altimeter 
hardware. 

The  MDM  control  logic  contains  a read-only  memory  by 
which  data  acquisition  and  distribution  programs  can  be 
preselected  in  any  desired  sequence  independent  of  IOM 
channelization.  This  capability  permits  the  acquisition 
and  distribution  of  large  blocks  of  subsystem  data  using 
a single  command  word  that  contains  the  program  starting 
address  and  length.  Input/output  data  processing  can  also 
be  controlled  by  direct  instructions,  thus  bypassing  the 
read-only  memory.  The  MDM  design  also  includes  an  exten- 
sive built-in  test  capability.  Self-check  capabilities 
include  functional  and  accuracy  tests  on  the  control 
logic,  power  supplies,  analog-to-digital  converters,  and 
all  input/output  channels  except  those  on  a special  Tacan/ 
radar  altimeter  module. 

The  MDM  circuits  are  partitioned  functionally  into 
plug-in  modules,  and  almost  all  electrical  components  are 
packaged  using  hybrid  circuit  technology.  An  MDM  typically 
contains  300  hybrid  circuits  of  80  different  types.  The 
Orbiter  MDM  dimensions  are  13  by  10  by  7 inches,  and  the 
weight  is  approximately  35  pounds.  The  SRB  MDM  dimensions 
are  11  by  10  by  8 inches,  and  the  weight  is  approximately 
28  pounds.  The  MDM  power  consumption  ranges  from  38  to  60 
watts  depending  on  IOM  configuration  and  operational 
requirements. 


DATA  BUS  SYSTEM  MANAGEMENT  PLAN 


The  decision  to  use  a single  data  bus  subcontractor 
was  influenced  primarily  by  the  Space  Shuttle  schedule 
requirements,  which  dictated  a relatively  short  development 
period  for  the  avionics  hardware.  These  scheduling  require- 
ments necessitated  concurrent  development  of  the  BTU's  and 
the  data  bus  transmission  system.  It  was  believed  that  the 
interfacing  of  avionics  subsystem  elements  with  buyer- 
supplied  MIA's  that  had:  standard  logic  level  interfaces  and 
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clocked  data  transfers  would  be  a smaller  development  risk 
than  requiring  each  BTU  developer  to  design  to  the  analog- 
type  requirements  of  a serial  multiplex  data  bus.  In 


addition,  the  use  of  a single  data  bus  supplier  would 
enable  test  and  evaluation  of  the  data  transmission  system 
throughout  its  development. 

The  selected  approach  to  data  bus  development  was  not 
without  anticipated  problems.  If  the  BTU  suppliers  were 
to  integrate  buyer-furnished  MIA  modules  into  their  designs, 
a detailed  MIA/BTU  interface  must  be  defined,  prototype  MIA 
hardware  must  be  supplied  early  in  the  BTU  development,  MIA/ 
BTU  interface  problems  must  be  quickly  resolved,  and  MIA 
module  delivery  schedules  must  be  coordinated  with  BTU 
production  schedules.  In  response  to  these  considerations, 
a Data  Bus  System  Interface  Control  Plan  was  developed  to 
manage  the  data  bus  hardware  development  and  MIA/BTU 
integration.  The  key  elements  of  the  plan  are  described  in 
the  following  paragraphs. 


MIA/Host  BTU  Interface  Control 

A data  bus  interface  control  engineer  was  assigned 
the  responsibility  of  MIA/BTU  interface  control.  His 
duties  were  as  follows. 

1.  Review  and  approval  of  all  MIA/BTU  interface 
specification  changes 

2.  Analysis  and  resolution  of  all  MIA/BTU  interface 
problems 

3.  Development  of  a standardized  set  of  interface 
requirements  between  the  BTU's  and  the  data  bus  network 

4.  Development  of  a communications  system  to  ensure 
that  all  BTU  suppliers  were  cognizant  of  MIA/BTU  interface 
problems 

5.  Control  (through  the  procurement  organization)  of 
MIA  module  assignment  to  the  BTU  vendors 

6.  Disposition  of  failed  MIA  modules 

7.  Development  of  a consistent  set  of  tests  and/or 
analyses  for  the  verification  of  the  MIA/BTU  interface  at 
the  BTU  developer 
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Normally,  the  development  of  the  MIA/BTU  interface  require- 
ments would  also  have  been  the  responsibility  of  the  data 
bus  interface  control  engineer;  however,  the  interface 
requirements  had  been  defined  before  the  implementation  of 
this  plan. 


Data  Bus  System  Performance 

A data  bus  system  engineer  was  selected  whose  respon- 
sibilities included  development  of  the  overall  data  bus 
system  design  and  the  component  requirements,  approval  of 
all  procurement  specifications,  hardware  design  analysis 
and  performance  predictions,  and  direction  and  evaluation 
of  all  data  bus  system  testing  at  both  the  developer  and 
the  prime  contractor  facilities. 


Data  Bus  Hardware  Development 

The  development  of  the  data  bus  hardware  (MIA,  DBC , 
and  DBIA)  was  assigned  to  an  engineer  whose  responsibilities 
included  development  of  hardware  procurement  specifications, 
technical  and  administrative  monitoring  of  the  development 
subcontractor,  and  coordination  and  chairing  of  meetings 
between  the  data  bus  developer  and  the  BTU  suppliers  to 
resolve  MIA/BTU  interface  problems.  In  implementing  this 
plan,  the  prime  contractor  did  not  permit  the  BTU  suppliers 
to  directly  contact  the  MIA  developer  for  the  purpose  of 
discussing  interface  problems. 


Analysis  and  Testing 

A requirement  of  the  control  plan  was  that  verification 
testing  and  analysis  be  conducted  at  the  BTU  supplier,  at 
the  data  bus  hardware  supplier,  and  at  the  prime  contractor 
facilities.  The  BTU  supplier  was  responsible  for  verifying 
the  MIA/BTU  interface  and  the  BTU/data  bus  interface. 
Interface  parameters  requiring  verification  included  envi- 
ronmental interfaces,  electrical  power,  BTU  output  data 
signal  characteristics,  and  the  MIA/data  bus  interface. 

The  data  bus  hardware  supplier  was  required  to  develop 
analytical  models  and  computer  simulations  of  the  data  bus 
components  and  to  verify  data  bus  system  performance  by 
tests  on  selected  data  bus  configurations.  Analytical 
models  of  the  MIA's,  DBC,  and  data  bus  cable  for  conversion 
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into  computer  models  and  computer  simulation  runs  as  a 
function  of  electromagnetic  interference,  noise,  bus  fault 
conditions,  and  component  variations  were  required  to  deter- 
mine operating  parameters  such  as  error  rate,  throughput 
performance,  and  error-detection  capability.  Hardware 
test  requirements  included  individual  data  bus  component 
performance  verification  and  system-level  testing  on  selected 
data  bus  configurations  to  verify  computer  simulations  and 
to  determine  the  effects  of  data  bus  parameter  changes 
(cable  length,  stub  position,  faults,  etc.)  on  system 
performance.  Development  testing  and  analysis  requirements 
at  the  prime  contractor  included  system-level  testing  using 
prototype  BTU  and  data  bus  hardware  and  the  development  of 
a data  bus  system  computer  program  using  models  of  data  bus 
components  developed  by  the  data  bus  component  supplier. 
Avionics  system  tests  were  required  to  verify  hardware/ 
software  interface  compatibility  with  respect  to  data  bus 
error  rates  and  error-detection  capability.  These  tests 
also  enabled  the  determination  of  performance  margins. 


Problem/Failure  Resolution  and  Change  Control 

The  control  plan  provided  a systematic  approach  to 
problem  resolution  and  change  control.  When  the  resolution 
of  MIA,  MIA/BTU  interface,  or  data  bus  system  problems 
required  changes  to  data  bus  or  BTU  hardware,  impact 
statements  were  obtained  from  all  affected  hardware  suppliers 
and  were  evaluated  by  the  prime  contractor  before  the 
implementation  of  hardware  specification  changes. 


Hardware  Allocation 

The  control  plan  specified  that  the  BTU  supplier 
requirements  concerning  MIA  deliveries  were  to  be  monitored 
continuously  by  both  material  and  engineering  personnel. 

The  MIA  delivery  priorities  were  to  be  determined  as  a 
function  of  MIA  availability,  BTU  delivery  criticality,  and 
MIA  failure  experience  so  that  impacts  to  the  Space  Shuttle 
Program  caused  by  MIA  shortages  would  be  minimized. 


DEVELOPMENT  PROBLEMS 


Both  management  and  technical  problems  became  evident 
during  the  development  of  the  data  bus  system  elements. 


Several  problems  that  were  not  unexpected  appeared  early 
in  the  hardware  development  program.  Several  of  the  BTU 
suppliers  were  competitors  of  the  MIA  developer,  and  there 
was  a natural  reluctance  to  use  another  company's  hardware 
in  their  equipment.  In  one  case,  the  BTU  supplier  had 
already  been  given  permission  to  develop  an  MIA  before  the 
decision  was  made  to  implement  the  single-design  MIA  concept. 
As  a result,  the  prime  contractor's  MIA/BTU  integration 
task  became  exceedingly  difficult;  many  of  the  early  inter- 
face problem-resolution  meetings  tended  to  be  more  political 
than  technical.  The  fact  that  the  availability  of  MIA's 
constrained  the  BTU  hardware  deliveries  created  problems 
because  the  BTU  suppliers  had  a tendency  to  request  very 
conservative  lead  times  for  MIA  deliveries..  In  addition, 
problems  were  caused  by  the  necessity  for  simultaneous 
development  of  the  MIA  and  BTU  hardware.  Changes  to  the 
MIA  specifications  due  to  inevitable  development  and 
interface  problems  were  difficult  to  resolve  and  often 
affected  BTU  hardware  designs  and  development  schedules. 

The  resolution  of  these  problems  required  a considerable 
amount  of  management  effort  and  firmness  on  the  part  of 
the  prime  contractor. 

The  first  major  technical  difficulties  encountered 
concerned  MIA  interface  definition.  The  physical  dimensions 
were  difficult  to  resolve  because  of  the  different  packaging 
techniques  used  by  the  various  BTU  suppliers.  The  resolution 
of  these  issues  resulted  in  the  decision  to  develop  two  MIA 
packages : one  for  the  CPU/IOP  and  a common  MIA  for  the 

other  BTU's.  The  packaging  was  especially  difficult  in  the 
CPU/IOP  because  of  the  24  MIA's/IOP  requirements;  therefore, 
it  was  decided  to  package  two  MIA  circuits  into  a dual  MIA 
(DMIA)  unit.  The  MIA  for  the  other  BTU's  was  then  called 
the  serial  MIA  (SMIA)  because  of  its  MIA/BTU  serial  inter- 
face. Another  significant  physical  issue  was  the  MIA 
mounting  connector.  Several  of  the  BTU  suppliers  were 
unfamiliar  with  the  NAFI  connector  system  selected  by  the 
MIA  developer  and  objected  to  its  use  because  of  the 
special  tooling  required.  This  issue  was  resolved  by 
eliminating  the  interface  connector  and  substituting  a pin- 
out arrangement  that  allowed  the  MIA  interface  pins  to  be 
soldered  directly  to  the  BTU  mounting  surface.  This 
arrangement  also  allowed  reduction  of  the  MIA  overall  length 
to  a dimension  acceptable  to  all  BTU  suppliers. 

Several  issues  involving  electrical  interface  require- 
ments also  became  apparent  early  in  the  program.  The 
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DMIA/IOP  electrical  interface  was  complicated  by  the 
"physical  space  available"  problems  previously  discussed. 

The  serial  interface  concept  was  not  directly  compatible 
with  an  internal  multiplex  bus  of  the  IOP  design  approach. 
This  problem  was  resolved  by  incorporating  certain  IOP  bus 
circuits  into  the  DMIA's.  The  acceptance  of  the  SMIA 
serial  interface  by  the  various  BTU  suppliers  was  not  a 
management  problem,  but  technical  problems  did  appear  during 
SMIA/BTU  integration.  These  problems  were  due  to  a combina- 
tion of  SMIA  interface  specification  inadequacies  and  BTU 
supplier  misinterpretations.  Problems  evolved  because  the 
objective  of  the  SMIA/BTU  interface  electrical  specifications 
was  to  provide  sufficient  handshaking  and  timing  signals  to 
allow  the  BTU  suppliers  some  design  flexibility  in  the 
transfer  of  data  and  error  flags  between  the  SMIA  and  BTU. 

As  a result,  some  BTU  designers  used  the  interface  signals 
in  a manner  not  anticipated  by  the  prime  contractor  and  not 
provided  for  in  the  interface  specification  signal 
definitions  and  tolerances.  These  problems  were  resolved 
as  they  occurred,  but  they  did  cause  perturbations  to  both 
the  SMIA  and  BTU  designs. 

Thermal  and  vibration  interface  considerations  became 
a problem  during  BTU  hardware  development.  The  MIA  module 
is  a printed  circuit  card  that  is  mounted  to  the  BTU  heat 
sink  with  seven  retaining  screws.  Several  of  the  BTU 
suppliers  mounted  the  MIA  onto  a BTU  plug-in  module,  which 
added  more  structure  through  which  heat  had  to  flow  than  if 
the  MIA  components  had  been  mounted  directly  to  the  BTU 
printed  circuit  boards.  The  heat-transfer  problem  was  also 
complicated  by  the  MIA  packaging  technology,  which  resulted 
in  the  MIA  signal  drivers  and  other  high-power-consuming 
components  being  mounted  in  a single  hybrid  circuit  package. 
The  subsequent  heat-transfer  inefficiencies  resulted  in  MIA 
components  operating  at  or  near  the  upper  acceptable  tempera- 
ture limit  when  the  BTU  was  subjected  to  worse-case  envi- 
ronments. The  MIA/BTr • mounting  technique  also  introduced 
a vibration  amplifies  .ion  factor  that  would  have  been  avoided 
if  MIA  components  had  been  mounted  directly  to  the  BTU 
printed  circuit  boards.  Vibration  and  thermal  interface 
issues  have  been  a major  problem  because  the  integrating 
contractor  could  not  directly  resolve  these  MIA  and  BTU 
environmental  specification  incompatibilities.  The  final 
resolution  was  that  BTU  qualification  would  also  qualify 
the  MIA  in  that  application.  Vibration  considerations 
have  also  caused  a third.  MIA  package  (SRB  MIA)  to  be  added 
to  the  Space  Shuttle.  The  MDM  and  MIA  requirements  for 
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the  SRB's  were  determined  after  the  SMIA  development  phase; 
therefore,  the  SMIA  printed  circuit  board  was  thickened  to 
accommodate  the  new  vibration  spectrum  requirements. 

Several  system-level  problems  concerning  IOP-to-BTU 
communication  were  encountered  during  the  data  bus  hardware 
development.  The  first  problem  concerned  the  time  between 
words  in  a transmitted  message  (interword  gap  time) . During 
the  early  CPU/IOP  development  phase,  the  intricacies  of  the 
CPU/IOP  interface  timing  and  IOP  microcode  design  caused 
the  interword  gap  time  to  be  changed  several  times  over  a 
6-month  period.  This,  of  course,  severely  affected  BTU 
development  because  of  the  instability  of  the  data  bus 
timing  requirements.  A second  area  of  difficulty  was  the 
definition  of  the  BTU  status  bits,  which  were  part  of  all 
data  bus  response  data  words  transmitted  by  the  BTU's  to  the 
CPU/IOP.  The  evolution  of  the  IOP  design  resulted  in  a 
requirement  that  these  status  bits  be  transmitted  as  a 101 
pattern  when  they  were  not  indicating  a BTU  internal 
problem,  failure,  or  other  abnormal  condition  that  would 
affect  data  quality.  This  problem  also  affected  BTU 
development,  and  design  changes  were  required  in  several 
BTU's. 


Another  major  system  integration  problem  was  an  offset 
in  the  transmitted  data  bus  signal  because  of  asymmetries 
between  the  positive  and  negative  pulses.  On  the  data  bus, 
the  problem  resulted  in  a slowly  decaying  tail-off  at  the 
end  of  the  word  that  was  dependent  on  the  bit  pattern 
transmitted  and  the  reactive  impedance  component  of  the 
bus  load.  This  phenomenon  caused  problems  primarily  in  the 
transmitting  DMIA's  because  the  offset  generated  an  erro- 
neous "MIA  busy  signal,"  which  is  used  by  the  IOP  to  control 
issuance  of  the  next  word  to  be  transmitted.  The  problem 
was  eventually  traced  to  an  improper  rise  time  on  the  clock 
signal  supplied  to  the  MIA  by  the  IOP.  Also,  the  offset 
trimming  procedures  for  the  MIA  were  determined  to  be 
extremely  critical  and  required  precise  measurements. 

One  of  the  more  troublesome  development  problems  was 
the  estimation  of  the  data  bus  noise  levels  that  will  be 
experienced  with  the  system  in  actual  use.  This  problem 
affected  both  the  specification  requirements  and  the 
development  test  program.  The  estimation  problem  had 
several  facets,  including  spectral  content,  amplitude, 
and  correlation.  Early  in  the  program,  no  applicable 
information  was  available  from  other  programs;  the 
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specification  therefore  copied  the  earlier  B-l  bomber  data 
bus  requirements.  Although  more  information  has  become 
available,  this  specification  has  not  been  changed  and  thus 
has  determined  the  verification  testing  method.  This  speci- 
fication assumed  a white  Gaussian  noise  spectrum,  band 
limited  from  1 kilohertz  to  4 megahertz.  A worst-case  noise 
level  of  300  millivolts  rms  was  assumed  to  be  present 
differentially  on  the  bus  lines  with  a specified  minimum 
amplitude  signal  of  1.5  volts  peak.  This  white  Gaussian 
noise  was  known  to  be  incorrect  but  represented  a convenient 
mathematical  expression  that  hopefully  would  be  applicable 
to  the  real  environment.  The  contractor  assumed  a data 
correlation  determined  by  the  MIA  input  filter  character- 
istics and  the  Gaussian  noise  distribution. 

Subsequent  analyses  have  shown  that  the  most  likely 
sources  of  noise  will  be  coupled  digital  logic  and  clock 
signals  from  the  host  BTU.  There  will  also  be  some  cross- 
talk between  buses  where  the  lines  run  through  connectors 
because  the  twisting  is  compromised  at  this  point.  Analysis, 
however,  indicates  that  the  signals  coupled  into  a bus  will 
be  effectively  differentiated  by  the  inductive  coupling 
mechanism  and  thus  shifted  in  frequency  above  the  bandwidth 
of  the  MIA  receiver  filter.  Current  estimates  indicate 
that  the  original  noise-level  immunity  required  by  the  MIA 
specification  was  conservative,  although  the  crucial  test 
will  occur  when  the  system  integration  is  completed  and 
the  actual  environment  is  experienced. 

Closely  related  to  the  uncertainty  of  the  noise  envi- 
ronment is  the  error-rate  requirement  that  must  be  met  in 
that  environment.  Originally,  an  actual  system  error-rate 
requirement  could  not  be  determined  because  of  the  many 
levels  of  error-forgiving  redundancy  within  the  baselined 
avionics  system.  This  problem  has  since  been  analyzed 
exhaustively  with  only  limited  success.  To  facilitate  the 
release  of  a specification,  the  bit  error-rate  requirement 
of  the  B-l  bomber  electrical  multiplex  (EMUX)  system  was 
increased  by  an  order  of  magnitude  and  used.  This  created 
a verification  problem  because  most  studies  and  textbooks 
define  error  rates  in  terms  of  bit  error  rates,  although, 
in  actual  implementation,  only  word  or  total  message  errors 
have  meaning.  Thus,  bit  errors  cannot  be  measured.  For 
this  reason,  it  was  necessary  to  clarify  the  specification 
by  translating  the  bit  error-rate  requirement  into  a some- 
what equivalent  word  error-rate  requirement.  This  change 
was,  in  fact,  more  stringent  because  errors  occurring  in 
the  detection  of  the  synchronization  pattern  had  to  be 
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included  in  the  calculations.  Synchronization  detection 
has  proved  to  be  a much  more  difficult  task  than  bit 
detection  because  the  pattern  occurs  asynchronously  when 
the  bus  noise  level  is  at  maximum.  With  the  current 
Shuttle  bus  design,  the  interword  period  is  an  off-state, 
with  the  bus  representing  a slightly  higher  impedance 
than  the  driven  state.  This  condition  results  in  a maximum 
likelihood  that  noise  will  exceed  thresholds  and  trigger 
the  MIA  receiver -detection  circuits.  Bit  detection, 
however,  is  synchronous  to  the  previously  detected 
synchronization  pattern  and  thus  offers  a great  advantage. 

In  addition,  the  bus  is  being  driven  well  above  the  detec- 
tion thresholds.  This  condition  results  in  exceptional 
noise  immunity  with  only  minor  effects  produced  during  the 
signal  rise  and  fall  times.  Error-rate  performance  has 
been  difficult  to  determine  accurately  by  testing  because 
of  the  performance  sensitivity  of  the  MIA  to  parameters 
such  as  signal  amplitude  and,  particularly,  rise  time; 
noise  amplitude,  bandwidth,  and  spectrum;  temperature; 
and  supply  voltages.  The  statistical  nature  of  error 
rates  also  caused  testing  difficulty.  This  condition 
affected  test  repeatability  and  necessitated  lengthy  tests 
to  obtain  statistically  significant  samples. 

Finally,  performance  verification  of  the  data  bus 
system  with  the  MIA's  in  place  within  the  host  BTU  has 
presented  problems.  The  varied  functional  capabilities  of 
these  BTU 1 s prevented  the  use  of  a single  testing  technique. 
Some  of  the  BTU's  have  the  capability  to  transmit  onto 
the  bus  and  some  do  not.  An  additional  problem  was  that 
some  BTU  vendors  had  neither  the  knowledge  nor  the  test 
capability  to  perform  error-rate  tests.  Thus,  the  BTU 
error-rate  testing  is  being  performed  by  the  prime 
contractor  in  their  system  testing  facilities  and  onboard 
the  vehicle.  These  tests  necessarily  can  only  measure 
message  error  rates  from  which  word  error  rates  must  be 
related. 


DISCUSSION 


The  first  Space  Shuttle  Orbiter  vehicle  is  presently 
undergoing  predelivery  checkout  and  acceptance  testing  at 
the  prime  contractor  facility;  flight  tests  are  scheduled 
to  begin  in  March  1977.  Although  the  data  bus  system  has 
not  accumulated  any  flight-test  time,  most  of  the  data  bus 
system  has  been  thoroughly  performance  tested.  The 


experience  gained  from  the  data  bus  development  and 
verification  test  phases  of  the  Space  Shuttle  Program 
has  generally  validated  the  design,  management,  and 
integration  choices  for  the  data  bus  system.  However, 
several  problem  areas  could  have  been  avoided  had  the 
program  been  handled  differently.  The  following  discussion 
reviews  the  program's  strengths  and  weaknesses  and  offers 
suggestions  for  the  avoidance  of  similar  problems  in 
future  data  bus  system  developments. 

Although  the  number  of  physical  and  environmental  MIA/ 
BTU  interface  problems  encountered  could  have  been  reduced 
by  permitting  the  BTU  suppliers  to  mount  the  MIA  components 
(hybrids,  transformers,  etc.)  directly  to  BTU  printed 
circuit  boards,  it  is  believed  that  supplying  the  MIA's  to 
the  BTU  suppliers  as  functional  units  was  the  better 
approach.  As  modules,  the  MIA's  could  be  acceptance  tested 
at  the  MIA  supplier's  facility  and  delivered  to  the  BTU 
vendors  as  tested  and  qualified  units.  The  uncertainties 
regarding  the  effects  of  the  BTU  supplier's  printed  circuit 
layout  on  MIA  performance  were  also  eliminated  as  potential 
issues. 

Although  its  implementation  was  a difficult  management 
problem,  the  single-design  MIA  approach  has  benefitted  the 
program  in  several  aspects.  The  ability  to  perform  systems 
analysis,  run  computer  simulations,  and  conduct  data  bus 
performance  testing  before  delivery  of  BTU  breadboard  and 
prototype  hardware  provided  a valuable  data  base  that  was 
used  advantageously  by  the  avionics  system  hardware  and 
software  design  disciplines  and  in  data  bus  network  layout 
design  on  the  Orbiter  vehicle.  This  data  base  also 
permitted  the  BTU/data  bus  interface  portion  of  BTU  accep- 
tance and  qualification  testing  to  be  limited  to  transmitter 
waveform  measurements  and  functional  verification  of  the 
interface,  thus  eliminating  the  need  for  qualitative  data 
bus  receiver  performance  testing.  In  addition,  the  required 
system-level  verification  testing  in  the  avionics  labora- 
tories and  on  the  vehicle  has  been  reduced  because  of  the 
extensive  data  bus  computer  simulations  performed.  For 
example,  data  bus  signal-level  and  waveform  measurements 
had  only  to  be  made  at  enough  BTU/data  bus  interfaces  on  the 
Orbiter  vehicle  to  verify  the  accuracy  of  the  computer 
simulations  which  had  previously  shown  that  signal  quality 
at  all  BTU  inputs  was  adequate.  Generally,  problems  were 
discovered  and  resolved  in  the  early  phases  of  hardware 
development  and,  consequently,  no  MIA/BTU  interface  problems 


70 


or  problems  affecting  system  design  (except  for  the  signal 
offset  problem  described  earlier)  have  been  found  in  the 
Space  Shuttle  avionics  test  facilities  or  on  the  Orbiter 
vehicle. 

Two  of  the  major  lessons  learned  (or  relearned)  from 
this  program  were  that  interface  signal  characteristics 
cannot  be  overdefined  and  that  interface  design  flexibility 
invites  interface  design  problems.  The  program  would 
probably  have  encountered  fewer  MIA/BTU  interface  design 
problems  if  fewer  interface  design  options  had  been  offered 
to  the  BTU  designers  and  if  the  remaining  interface  signals 
had  been  better  defined. 

Future  data  bus  performance  specifications  should  not 
overlook  signal  rise/fall  time  requirements  in  the  speci- 
fication of  signal  parameters  for  signal/noise  performance 
testing  of  the  data  bus  receiver /decoder . With  all  other 
signal  parameters  and  noise  remaining  constant,  error  rates 
can  vary  several  orders  of  magnitude  as  signal  rise/fall 
times  range  from  100  to  200  nanoseconds.  Because  this 
parameter  was  specified  in  the  MIA  signal/noise  performance 
test  criteria,  the  MIA  was  qualified  using  rise/fall  times 
selected  to  optimize  test  results  and  not  to  reflect 
expected  rise/fall  times  at  the  BTU's  in  the  Space  Shuttle 
data  bus  networks. 

If  a single-design  MIA  approach  is  chosen  for  future 
data  bus  system  developments,  it  is  recommended  that  the 
BTU  suppliers  be  required  to  utilize  the  MIA  or  other  buyer- 
supplied  data  bus  interface  devices  in  their  BTU  acceptance 
test  equipment.  Because  this  was  not  done  in  the  Space 
Shuttle  Program,  the  prime  contractor  was  unable  to  specify 
uniform  BTU/test  equipment  interface  signal  characteristics 
during  BTU  acceptance  and  qualification  testing. 

The  motivation  to  create  a Data  Bus  System  Interface 
Control  Plan  was  as  much  a result  of  early  developmer t 
problems  as  of  good  management  planning.  Obviously,  earlier 
implementation  of  this  plan  would  probably  have  reduced  the 
severity  of  program  impacts  resulting  from  problems 
encountered  in  the  early  phases  of  data  bus  hardware 
development.  It  is  recommended  that  agencies  or  companies 
requiring  similar  systems  in  the  future  implement  a system 
management  plan  before  initiating  development  activities. 
This  is  especially  important  if  the  development  task 
involves  the  integration  of  system  elements  provided  by  a 
multiplicity  of  subcontractors. 
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SUMMARY 

Today,  avionics  are  demanding  an  increasing  proportion  of 
the  resources  available  for  aircraft  weapon  systems.  These 
avionics  are  providing  increased  capability  and  accuracy  to 
the  aircraft  weapon  system;  but,  also  are  a prime  contributor 
to  increased  complexity  and  decreased  reliability  of  the  sys- 
tem. Digital  avionics  appears  to  offer  the  desired  increase 
in  capabilities  and  performance  without  the  normal  companions 
of  low  reliability,  complexity,  and  high  cost  because  it  is 
amenable  to  mechanization  via  solid  state  devices;  it  is  more 
orderly  and  systematic,  and  provides  growth  and  change  with- 
out major  hardware  modification.  Digital  avionic  integration, 
in  order  to  reap  these  benefits,  requires  standard  equipment 
interfaces  and  a standard  approach  to  data  intercommunication . 
The  time  division  data  bus  is  the  technique  that  permits  this 
new  concept  of  system  integration  to  emerge.  This  paper  will 
present  the  data  bus  evolutions,  its  standardization  and  ap- 
plication. The  acquisition  management  and  logistic  benefits 
will  be  discussed. 

DEFINITIONS 

1.  Time  Division  Multiplexed  Data  Bus:  Throughout  this 

paper,  there  are  many  shortened  versions  of  it:  multiplex 

data  bus,  data  bus,  bus,  multiplexing,  MUX  and  MIL- STD- 1 5 5 3 . 

2.  Time  Division  Multiplexing  (TDM):  The  transmission 

of  information  from  several  signal  channels  through  one 
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communication  system  with  different  channel  samples  staggered 
in  time  to  form  a composite  pulse  train. 

3.  Remote  Terminals:  This  is  the  electronics  necessary 

to  interface  the  bus  with  the  sub-system  and  the  subsystem 
with  the  bus. 

4.  Bus  Controller:  The  controller  shall  be  a unit 

that  is  either  programmable,  or  controlled  by  a processor, 
and  that  serves  the  function  of  commanding,  scanning  and 
monitoring  bus  traffic. 

5.  Message : A message  is  a transmission  of  words  on 

the  data  bus  cable.  A message  transfer  is  complete  when  the 
command  word,  data  word(s)  and  the  status  word  have  been  trans- 
mitted. There  are  three  types  of  messages:  controller  to 

terminal,  terminal  to  controller  and  terminal  to  terminal. 

6.  Words  in  a Message:  In  this  document  a word  is  a 

sequence  of  16  bits  plus  sync  and  parity.  There  are  three 
types  of  words:  Command,  Status  and  Data. 

INTRODUCTION 


Current  US  Air  Force  avionics  acquisition  practices 
breed  "black  box"  proliferation  resulting  in  high  cost,  low 
reliability,  and  a heavy  operating  and  maintenance  burden. 

1 2 

A study  ’ was  conducted  to  investigate  the  applica- 
bility of  digital  techniques  to  solve  today's  high  cost  and 
proliferation  of  aircraft  avionics.  It  was  found  that  in 
current  aircraft,  the  avionics  cost  is  approximately  one- 
third  of  the  total  system  acquisition  cost.  Because  of  the 
lack  of  a "standard"  integration  approach,  equipment  intro- 
duced into  inventory  is  generally  in  low  quantity  and  of  low 
reliability  and,  therefore,  results  in  a logistic  and  main- 
tenance nightmare.  Even  equipment  intentionally  starting 
out  identical,  ends  up  unique  because  of  the  different 
interface  requirements  in  different  systems,  causing  them 
to  become  incompatible. 

One  solution  proposed  by  the  study  group  was  to  view 
the  aircraft  avionics  as  in  "integrated  system"  rather  than 
a conglomerate  of  functional  sensors.  The  data  bus  concept 
forces  one  to  oerform  systems  level  analysis  because  infor- 
mation flow  definition  is  systems  integration  and  is  used  as 
the  key  element  in  the  orderly,  standard  integration  process 
of  avionic  equipment  (black  boxes). 
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Digital  avionics  will  be  used  more  and  more  in  current 
and  future  aircraft  systems  and  the  data  bus  will  be  the  key 
to  successful  integration.  Other  requirements  are  sensors 
built  to  the  bus'  standard  digital  interface,  the  liberal  use 
of  common  digital  computers,  mod ul ar /mul t ipur pos e controls 
and  displays  and  a standard  higher  order  software  language. 

When  utilizing  the  data  bus  concept,  it  is  important  to 
realize  that  a large  amount  of  the  integration  is  accomplished 
through  software.  Therefore,  the  final  and  most  critical  in- 
tegration step  is  performed  through  the  effective  application 
of  flight  software;  i.e.,  the  software  controls  the  realtime 
information  flow. 

THE  DATA  BUS 

The  digital  time-division  multiplex  data  bus  is  a tool  to 
aid  in  system  integration.  Origionally  introduced  to  save 
avionic  hardware  interconnect  wiring  weight  and  ease  computer 
interface  requirements,  it  is  now  considered  the  cornerstone 
of  digital  avionics.  Through  the  use  of  the  multiplexing 
technique,  many  other  benefits  can  be  reaped.  The  resultant 
standard  electronic  interface  permits  a building  block  approach 
to  systems  architecting  and  integration.  Retrofits  become 
easier,  standard  interchangeable  sensors  become  a reality,  and 
maintenance  is  greatly  improved.  Flexibility  is  probably  the 
data  bus'  greatest  attribute,  reliability,  built-in-test,  re- 
dundancy and  graceful  degradation  are  additional  benefits. 

These  gains  are  realizable  only  if  some  form  of  standardization 
is  adhered  to;  therefore,  a military  standard  was  develope^  £o 
provide  some  consistency  in  data  bus  design,  MIL-STD-1553A  ’ . 

This  standard  has  been  used  in  a number  of  Air  Force  a^d  Navy 
programs.  Many  new  applications  are  developing.  DAIS  is  a 
laboratory  program  to  help  define  and  explore  applications  of 
digital  avionics.  The  Air  Force  is  committed  to  the  application 
of  digital  avionic  techniques  and  the  multiplexed  data  bus  con- 
cept is  an  important  part  of  it. 

BACKGROUND 

Typical  signal  integration  is  difficult  because  sensor/ 
equipment  interfaces  are  unique  (non-standard  signal  character- 
istics) resulting  in  a significant  weight  and  volume  penalty 
in  large,  avionic  dispersed  aircraft  systems.  Each  subsystem 
has  its  own  unique  input/output  signalling  formats,  from  non- 
standard analog,  synchro,  discrete,  digital  serial  and  parallel, 
to  infinite  combination  of  these. 


The  majority  of  avionic  sensors  are  designed  to  provide 
data  in  an  analog  form  most  convenient  to  the  sensor  manufac- 
turer or  peculiar  to  a one-time  application.  Therefore,  the 
computer  contractor,  to  properly  communicate  with  the  sub- 
systems, must  build  a special  purpose  converter  unit  to 
interface  the  computer  with  these  subsystems.  Each  analog 
or  discrete  signal  is  routed  separately  from  each  subsystem 
to  this  central  converter.  The  converter  unit  provides  such 
things  as  signal  terminations,  conditioning,  sampling,  scaling 
and  conversion  to  the  proper  digital  format.  The  analog  to 
digital  and  digital  to  analog  converters  must  be  extremely 
high  speed  because  they  are  time  shared  among  all  the  input/ 
output  signals.  Often  this  converter  unit  is  twice  as  com- 
plex as  the  computer  and  highly  special  purpose.  That  is, 
if  any  signal  format  is  changed  or  a new  one  added,  there  is 
a definite  impact  on  the  converter  hardware.  Changes  are 
often  costly  and  major  avionic  modifications  impossible  with- 
out starting  from  scratch. 

A digital  avionic  multiplex  data  bus  has  a number  of  de- 
finite advantages.  Substantial  wire  savings  can  be  realized 
by  using  the  same  data  bus  in  a time  sharing  mode.  Wire  and 
connector  savings  show  up  as  weight  savings.  Ease  of  changing 
sensors  due  to  standard  interfaces  is  another  extremely  desir- 
able feature.  The  digital  transmission  technique  used  is  less 
susceptible  to  EMI  and  it  is  easier  to  detect  and  correct  errors. 
System  configuration  modifications  can  be  performed  by  properly 
changing  the  computer  software.  Computers  will  no  longer  become 
obsolete  because  they  will  be  truly  general  purpose  (i.e., 
special  purpose  converter  hardware  will  no  longer  be  an  integral 
part  of  it).  In  this  digital  bus  concept,  sometimes  called  MUX 
for  short,  the  sensors  that  provide  real  time  data  to  the  com- 
puter or  receive  data  from  it  are  all  tied  in  parallel  to  a 
common  multiplexed  data  bus.  Transmission  is  digital  under 
central  computer  control.  This  requires  federated  conversion 
and  federated  data  storage  in  a sensor  scratch  pad  memory.  The 
sensor  generates  the  data,  converts  it  and  stores  it  in  its  own 
scratch  pad  (remote  data  memory)  at  its  own  iteration  rate.  The 
central  computer,  under  software  control,  samples  these  data 
memories  as  required  by  the  operational  program  and  treats 
them  as  if  they  were  an  extension  of  the  central  computer's 
main  memory.  Data  gathering  is  accomplished  through  the  use 
of  the  computer  programmed  input/output  controller. 

An  interesting  advantage  to  this  technique  is  that  the  data 
transfer  rates  on  the  bus  are  much  lower,  requiring  a much  lower 
bandwidth  transmission  line.  A one  megahertz  data  transmission 


r* 


rate  Is  more  than  sufficient.  A data  word  is  transferred 
only  when  needed  rather  than  continuously  as  in  the  analog. 
(Continuous  transmission  is  required  in  the  analog  trans- 
mission technique  because  the  sensor  and  converter  hardware 
never  know  when  and  even  if  the  software  requires  the  newly 
generated  information.)  Consequently,  the  computer  memory 
must  always  be  updated  with  the  most  current  data.  In  the 
multiplex  data  bus  technique,  the  sensor  scratch  pad  memories 
are  treated  as  an  extension  of  the  computer's  main  memory  and 
their  use  is  under  program  control.  Therefore,  additions  and 
deletions  of  sensors  are  easily  accomplished.  Sensor  modifi- 
cations that  change  the  sensor's  analog  input/output  format 
will  require  the  sensor  contractor  to  modify  his  converter 
and  it  will  be  totally  his  responsibility  to  comply.  These 
modifications  will  then  be  performed  by  the  contractor  in  the 
sensors  own  lower  speed  converter  unit  requiring  only  software 
modifications  within  the  central  computer. 

SYSTEM  APPLICATIONS 

The  first  systems  application  of  this  type  of  a multi- 
plexed data  bus  was  in  the  integration  of  the  USAF's  F-15 
fighter  aircraft.  (Figure  1).  Some  of  the  reasons  why  the 
data  bus  was  originally  used  were: 

1.  Weight  savings  (wire,  connectors) 

2.  Simpler  wire  routing  in  aircraft  (fewer  bulkhead 
holes,  clamps,  connectors) 

3.  Fewer  data  transfers  (sensor  information  transmitted 
on  demand  only) 

4.  Ease  of  changing  sensors  (made  possible  because  of 
the  resulting  standard  interface) 

5.  Less  tendency  to  obsolescence  (sensors,  computers) 

6.  Less  electromagnetic  interference  (because  of  digital 
transmission) 

7.  Higher  reliability  (better  error  detection,  fewer 
hardwire  interconnections) 

8.  Permits  retrofits  (eases  modification  and  growth 
problems) 

9.  Lends  itself  to  simplified  built-in-tes t (BIT) 
techniques 
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Once  proven  feasible,  another  major  USAF  system,  the  B-l 
stratetic  bomber,  designed  its  avionic  system  around  the  data 
bus.  (Figure  2).  Three  separate  bus  systems  are  utilized  in 
the  B-l  avionic  systems. 

The  first  one,  quad  redundant,  is  used  for  electrical 
power  switching  control  and  management  (EMUX);  the  second, 
dual  redundant,  for  mission  avionic  sensor  integration,  both 
offensive  and  defensive  (AMUX) , and  the  third,  no  redundancy, 
for  bu i 1 t- in- t e s t purposes  called  "Centrally  Integrated  Test 
System"  (CITS). 

At  this  point  in  time,  an  undesirable  trend  was  perceived 
in  the  development  of  multiplex  data  bus  (MUX)  techniques, 
namely  that  MUX  systems  were  beginning  to  proliferate  to  an 
extent  which  was  threatening  to  obviate  the  gains  which  they 
have  provided  as  noted  above.  A number  of  different  MUX 
buses  had  been  built,  all  of  which  possessed  similar  architec- 
tures, data  rates,  encoding  techniques,  and  technology.  How- 
ever, there  was  sufficient  difference  in  their  signal  formats 
and  protocol,  interfaces,  and  functional  operation  to  pre- 
clude any  common  hardware  or  interfaces.  Further,  it  was 
apparent  that  the  use  of  MUX  techniques  was  spreading  into 
other  non- trad i t ional  avionic  areas  such  as  engine  management, 
stores  management,  flight  instrumentation  and  flight  controls. 

In  summary,  the  time  was  ripe  for  standardization  of  MUX  systems. 

Drawing  on  the  F-15  and  B-l  experience,  and  reviewing 
anticipated  future  avionics  needs,  a draft  standard  was  pre- 
pared that  resulted  in  MIL-STD-1553  (USAF),  30  Aug  1973. 

Resultant  tri-service  negotiations,  based  on  US  Navy  and 
Army  application  requirements,  caused  the  standard  to  be 
upgraded  and  it  was  published  as  a tri-service  document, 
MIL-STD-1553A,  on  30  April  1975  . 

THE  MILITARY  BUS  STANDARD 

MIL-STD-1553A , entitled  "Aircraft  Internal  Command/ 

Response  Time  Division  Multiplex  Data  Bus",  covers  the  over- 
all system  requirements,  architecture,  operational  protocol, 
and  interfaces  within  the  multiplexed  data  bus  system.  It 
is  intended  to  establish  uniform  requirements  for  all  multi- 
plex applications,  not  just  avionics,  and  provides  for  com- 
monality of  electronic  functions  and  interfaces  within  the 
total  air  vehicle.  The  standard  was  written  so  as  to  permit 
the  system  designer  a maximum  amount  of  design  flexibility 
while  retaining  a common  inter-weapon  system  interface.  As 
a result,  MIL-STD-1553A  must  be  employed  in  conjunction  with 
detailed  air  vehicle  or  subsystem  specifications. 
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OFFENSIVE  SUBSYSTEM 


B-l  Digital  System  Architecture 


Figure  3 illustrates  an  elemental  bus  configuration 
using  MIL-STD-1553A.  The  bus  system  has  three  major  com- 
ponents, the  bus  controller,  the  data  bus  itself,  and  re- 
mote terminals  or  subsystems.  The  bus  controller  acts  as 
the  focal  point  for  the  data  bus  and  the  integration  of 
the  sybsystems  connected  to  the  bus.  The  bus  controller 
is  a software  programmable  device,  a computer  or  dedicated 
microprocessor,  which  issues  the  commands  to  initiate  data 
transfers  over  the  data  bus.  No  remote  terminal  transmits 
a signal  without  the  transfer  being  initiated  by  the  con- 
troller; it  commands,  and  the  remote  terminals  respond, 
hence  the  description  "command/response"  architecture. 

When  growth  is  required  in  the  system,  the  new  subsystem 
is  added  and  given  a unique  address.  The  only  change  re- 
quired to  the  existing  equipment  is  a modification  to  bus 
controller  software,  thus  providing  a high  level  of  flexi- 
bility without  major  equipment  modifications. 

The  data  bus  itself  is  a shielded  twisted  wire  pair, 
operating  in  a classical  balanced  transmission  line  mode. 
Redundancy  (i.e.,  multiple  data  buses)  is  the  system  de- 
signers option  (Figure  4).  Transformer  coupling  is  used 
between  the  bus  and  the  terminals;  the  signal  on  the  bus  when 
transmitting  data  is  a serial  bit  stream,  Manchester  Bi-Phase 
Level  encoded,  and  transmitted  at  a 1.0  MHz  rate. 

The  remote  terminals  provide  that  hardware  necessary  to 
interface  the  subsystem  to  the  bus;  this  includes  transmitter/ 
receiver,  encotfer/decodei , error  checking,  and  holding  registers 
The  remote  terminal  may  .exist  as  a separate  line  replaceable 
unit  (LRU),  or  be  built  into  a subsystem  which  interfaces  to 
the  data  bus  (see  Figure  3).  In  general,  any  moderately  com- 
plex subsystem  (e.g.,  an  inertial  subsystem)  will  interface 
directly  to  the  bus,  whereas  the  relatively  simple  or  low 
data  rate  subsystems  (e.g.,  a TACAN > doppler  or  altimeter), 
would  interface  to  the  bus  through  a remote  terminal  which 
can  handle  more  than  one  of  these. 

Three  types  of  words  are  used  to  make  up  the  messages 
which  are  transmitted  between  subsystems  on  the  data  bus; 
Command,  Data  and  Status  words  as  shown  in  Figure  5.  Command 
words  are  only  transmitted  by  the  bus  controller.  Status  words 
only  by  remote  terminals,  and  Data  words  by  each.  All  words 
are  preceded  by  a unique  synchronization  waveform  which  is 
distinguishable  from  the  remainder  of  the  Manchester  encoded 
bits.  The  Command  word  is  divided  into  four  fields;  the  first  • 
being  the  address  of  the  terminal  to  which  the  Command  word  is 
directed;  second,  the  transmit/receive  bit  which  indicates  the 


remote  terminals  action;  third,  a subaddress /mode  field  to  be 


defined  by  the  remote  terminal  designer;  and  fourth,  a count 
of  the  number  of  words  to  be  transferred.  The  last  bit  in 
the  word  is  used  to  provide  odd  parity  over  the  preceding 
sixteen  bits . 

r 

The  Data  word,  which  contains  the  information  to  be 
transferred,  has  one  sixteen  bit  field,  followed  by  parity. 

The  Status  word,  which  is  always  transmitted  by  the 
terminal  in  response  to  a command  is  also  partitioned  into 
four  fields.  First  is  the  terminal  address;  second,  a message 
error  bit  to  indicate  the  failure  of  the  preceding  message 
(e.g.,  a parity  error  in  one  of  the  preceding  words  in  the 
message);  third,  nine  bits  which  can  be  used  for  defining 
status  codes;  and  fourth  the  terminal  flag  bit  which  in- 
dicates the  need  for  the  bus  controller  to  request  status 
and  self-test  information  from  the  terminal.  Parity  is 
also  provided  for  the  Status  word. 

The  Command,  Data,  and  Status  words  are  combined  to  form 
three  message  formats  as  shown  in  Figure  6.  A bus  controller 
to  remote  terminal  transfer  is  accomplished  by  the  controller 
sending  a receive  Command  word  followed  contiguously  by  the 
Data  words.  After  a specified  gap  time,  the  addressed  terminal 
responds  with  its  Status  word,  thus  indicating  proper  receipt 
of  the  message. 

A terminal  to  controller  transfer  is  initiated  by  the 
controller  sending  a transmit  Command  word  to  the  remote  ter- 
minal. After  the  gap  time,  the  addressed  terminal  responds 
with  a Status  word  contiguously  followed  by  the  specified 
number  of  Data  words. 

The  direct  terminal-to-terminal  transfer  may  be  effected 
by  a combination  of  the  two  previous  commands.  It  is  important 
to  note  that  continuous  "handshaking"  between  remote  terminals 
and  the  bus  controller  provides  a constant  system  health  moni- 
toring function,  thus  providing  an  inherent  bui 1 t- in- t es t 
(BIT)  capability  of  the  MUX  bus. 

The  system  designer  using  MIL-STD-1553A  still  retains  a 
high  degree  of  flexibility  in  his  design  approach  due  to  the 
nature  of  the  standard.  His  options  include  selecting  the 
redundancy  scheme  (dual,  triple,  or  quad?  - Figure  A)  de- 
termining the  bus  controller  implementation,  identifying 
criteria  for  selection  of  a signal  for  transmission  on  the 
bus,  defining  the  physical  configuration  of  the  bus  system, 
and  providing  functional  operation  algorithms.  Due  to  its 
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Flemental  Bus  Architecture 


Fig.  A Complex  Bus  Architectures 


Fig,  5 Message  Formats 
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flexibility,  MIL-STD-1553A  has  received  wide  acceptance  by 
industry  and  DoD,  and  has  already  been  applied  to  a large 
number  of  military  weapon  systems. 

APPLICATION  BENEFITS  OF  THE  DATA  BUS 

MIL-STD-1553A  is  being  applied  to  a variety  of  current 
weapon  systems,  both  as  an  integration  tool  to  reduce  air- 
craft wiring  and  to  increase  reliability  and  flexibility, 
and  also,  as  a standard  digital  interface  to  subsystems. 

The  following  systems  are  using,  or  contemplating  using  MIL- 
STD-1553A : F-16  (Figure  7),  F-18,  gAIS,  LAMPS,  RPV,  AMST  and 
Army  helicopters,  ATF.  NATO  AGARD  is  investigating  common- 
ality between  international  multiplex  data  buses. 

If  multiplexing  is  used  as  an  integration  technique  in 
weapon  systems,  great  standardization  benefits  can  be  realized. 
Multiplexing  defines  the  way  information  flows  on  the  data  bus 
and  also  the  protocol  needed  to  accomplish  orderly  data  trans- 
fers. This  enables  one  to  define  two  standard  interfaces;  one 
to  the  avionic  subsystems  that  have  digital/discrete  inputs/ 
outputs  and  the  other  directly  to  the  data  bus  (twisted  pair) 
for  subsystems  that  have  the  multiplexed  remote  terminals  built 
in  (Figure  3).  All  this  is  defined  in  MIL-STD-1553A. 

Other  standardization  tasks  are  now  underway  in  the  area 
of  airborne  computers  and  its  application  and  support  software, 
multipurpose  controls  and  displays  and  sensors  with  standard 
interfaces.  Because  digital  techniques  are  expanding  into 
areas  that  were  formerly  purely  electrical  and/or  mechanical 
in  nature  (i.e.,  electrical  power  control  and  flight  control, 
etc.)  the  AF  Digital  Avionics  Study  has  proposed  to  change 
the  definition  of  "avionics"  to  "airborne  electronics".  This 
is  why  processors,  software  and  multiplexing  are  appearing  in 
so  many  new  disciplines.  Because  not  all  the  electronics  for 
these  disciplines  are  always  procured  simultaneously,  much 
proliferation  can  occur  in  the  air  vehicle  hardware.  That 
is  why  multiplexing  is  so  readily  accepted.  It  gives  the 
systems  engineer  a building  block  approach  to  system  design 
and  permits  standardization  throughout  the  total  weapons 
system.  Subsystems  not  yet  available  can  easily  be  simulated 
and  then  substituted  later  when  delivered,  i.e.,  systems  inte- 
gration is  no  longer  delayed  until  all  parts  are  delivered. 

Another  benefit  derived  from  the  MUX  standard  is  that 
it  permits  one  to  establish  an  in-house  systems  engineering 
capability.  In  order  to  get  a better  handle  on  avionics,  one 
can  investigate  the  feasibility  of  performing  systems  analysis 


in-house,  thus  accomplishing  your  own  top  level/functlonal 
systems  definition  and  architecting.  This  type  of  system 
simulation  allows  one  to  investigate  the  data  flow  correct- 
ness and  systems  performance  based  on  data  accuracy,  timing 
and  availability.  Redundancy  and  graceful  degradation  can 
be  realistically  simulated  to  find  out  critical  parameters 
and  system  sensitivity  to  various  signals  and  their  accuracy. 

This  approach  to  systems  integration/architecting  will  reduce 
cost  by  avoiding  over-specification  of  equipment,  it  reduces 
risk  through  early  systems  simulation  prior  to  specification 
writing,  and  it  increases  realiability  through  performing 
failure  analysis  and  applying  well  defined  built-in-test 
(BIT)  and  graceful  degradation/redundancy  schemes. 

Other  benefits  that  multiplexing  provides  can  be  realized 
in  system  retrofits  and  in  the  maintenance  and  logistics  area. 
Systems  retrofits  are  more  easily  accomplished  because  of  the 
standard  interfaces  of  systems  and  time  sharing  of  aircraft 
wiring  (i.e.,  MUX  Bus).  In  the  maintenance  area,  the  data  bus 
enables  dynamic  testing  of  on-board  equipment  and  standard 
ground  support  equipment.  In  the  logistics  area  the  prime 
benefit  is  fewer  inventory  parts  (at  all  levels)  and  in- 
creased reliability  of  the  hardware. 

In  summary,  to  reiterate,  by  first  standardizing  the  multi- 
plexed data  bus  (MIL-STD-1553A)  , and  following  it  up  with  similar 
standards  that  are  developed  for  reducing  proliferation  in  com- 
puters and  software,  the  following  overall  benefits  can  be 
gained : 

1.  Systems  integration/architecting  will  be  simplified. 

2.  Standardization  of  interfaces,  hardware  and  software 
will  reduce  proliferation. 

3.  Retrofit  and  maintenance  of  digital  avionic  systems 
will  become  easier. 

4.  Reliability  of  hardware  will  be  increased  and  the 
resultant  reduction  of  inventory  equipment,  parts  and  documen- 
tation will  reduce  life  cycle  costs. 

5.  There  will  be  more  international  competition  in  avionics 
hardware/software  because  of  the  standard/compatible/interchange- 
able sensors  that  can  be  developed  off-line. 

Therefore,  it  is  felt  that  even  though  the  multiplex  data  bus 
is  only  a portion  of  the  overall  digital  avionics  concept,  it 
has  laid  the  cornerstone  for  the  concept  by  providing  a standard 
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Integration  concept  with  standard  equipment  interfaces  that  is 
reconf igurable  and  technology  independent  and  as  a result  the 
many  benefits  listed  in  this  paper  can  be  realized. 
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GPMS  DEVELOPMENT  PROGRAM: 


The  objective  of  the  GPMS  (General  Purpose  Multiplex 
System)  development  program  is  to  provide  a flexible  multi- 
plex bus  system  which  will  increase  the  operational  capability 
and  maintainability  of  the  aircraft. 

In  order  to  accomplish  this,  the  GPMS  program  initiated 
a concept  definition  based  on  several  requirements. 

a.  Multimission  (Fighter-Attack-Patrol) 

b.  Interface  with  Ships  (Aircraft  Deck  Operations) 

c.  Backward  and  Forward  Compatibility  (Existing  MUX 
Implementation) 

d.  Service  Various  Aircraft  Processing  Architectures 
(Central,  Federated,  Distributed) 

e.  Tri-Service  Compatible 

The  first  milestone  of  the  program  was  reached  in  FY-75 
with  the  delivery  of  GPMS-X  model  hardware  to  NAVAIRDEVCEN. 
This  hardware,  which  operated  as  per  NAVAIRDEVCEN  Specifica- 
tion AN/UCC ( ) XJ  203-1  of  May  1973,  was  developed  by  Tele- 
phonies, a Division  of  ISC,  of  Huntington,  Long  Island,  New 
York.  The  contract  was  awarded  after  a competitive  RFP. 

The  basic  configuration  of  the  203-1  specification  was 
based  on  the  SDMS  (Ships  Data  Multiplex  System)  architecture 
with  technical  support  from  NELC,  Autonetics,  and  Semcor, 

Inc . 

It  is  important  to  mention  that  the  configuration  of  the 
203-1  specification  and  follow-on  hardware  did  allow  us  to 
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accommodate  the  SOSTEL  (Solid  State  Electrical  Logic)  command/ 
response  system  (Quasi  1553A  - 22  bit  structure). 

At  the  present  time  this  hardware  is  installed  in  the 
Boeing  720  Flying  Test  Bed  undergoing  test  to  evaluate  the 
ability  of  the  polling  mode  to  service  various  signal  data 
flow  and  also  provide  a vehicle  for  a Fiber  Optic  party-line 
data  bus  system.  This  work  is  being  performed  in  conjunction 
with  Boeing,  NELC,  and  the  Army. 

Following  this  activity  the  DDR&E,  Tri-Service,  and  in- 
dustry (SAE)  multiplex  community  took  up  the  task  of  defining 
and  agreeing  upon  a standard  to  govern  the  operation  of  a 
command/response  multiplex  data  bus.  The  result  of  this 
effort  was  M1L-STD-1553A . From  the  point  of  view  of  the  GPMS 
overall  program  such  a standard  was  mandatory.  First,  because 
it  insured  a common  tri-service  command/response  structure 
which,  in  effect,  results  in  a requirement  to  accommodate  only 
one  command/response  structure  and  not  any  number  of  struc- 
tures. Secondly,  a frame  of  reference  was  now  available  from 
which  to  define  a compatible  message  format  and  protocol  for 
the  polling  mode  of  operation.  Thirdly,  the  GPMS  program  was 
not  in  a position  to  define  a dual-mode  specification  which 
would  provide  multiplex  system  hardware  capable  of  operating 
in  either  the  1553A  mode  or  the  polling  mode.  This  dual  mode 
capability  now  provides  to  the  GPMS  configuration  the  ability 
to  service  a wide  variety  of  aircraft  processing  architectures 
(central,  federated,  distributed).  Navy  specification  MIL- 
G-85013  (AS)  (MIL-E-XXX)  of  21  March  1975  is  the  resultant 
specification  defining  a dual-mode  multiplex  system  capability. 

The  next  major  milestone  is  the  October  1976  delivery  of 
dual-mode  terminals  to  NAVAIRDEVCEN  by  both  Telephonies  and 
Grumman.  These  terminals  will  under-go  tests  while  servicing 
the  AAES  (Advanced  Aircraft  Electrical  System)  program  objec- 
tives and  the  BASIC  (Basic  Avionics  Subsystem  Integration 
Concept)  laboratory  configuration. 

For  the  FY-77  a development  effort  has  been  initiated  for 
a five  station  Audio  Multiplex  Intercom  System  (two  to  twenty 
station  capability)  within  the  context  of  a General  Purpose 
System's  approach.  Additionally,  an  effort  is  on-going  for 
the  definition  of  a wideband  system  to  service  the  require- 
ment of  advanced  subsystems  (TIES  (Tactical  Information  Ex- 
change System) , AIDS  (Advanced  Integrated  Display  System) ) . 


SUMMARY : 


As  a result  of  the  GPMS  program  the  Navy  will  be  in  a 
position  to  propose  to  the  tri-service  and  industry  community 
a dual-mode  expanded  1553A  capability  which  will  be  compatible 
with  the  basic  1553A  implemented  aircraft  as  well  as  provide 
a capability  to  service  a wide  range  of  processing  architec- 
tures. 


DIGITAL  AVIONIC  INFORMATION  SYSTEM  (DAIS) 
MULTIPLEX  SYSTEM 

Capt  Frederick  L.  Pensworth 

Air  Force  Avionics  Laboratory 


ABSTRACT 

The  protocol  or  system  control  procedures  for  a given 
system  directly  affects  the  design  of  hardware  for  the  multi- 
plex system.  Protocol  is  defined  as  the  error  management, 
position  control  and  standard  communication  associated 
with  the  multiplex  data  bus.  A system  control  procedure 
is  required  to  define  operations  such  as  system  start  up/ 
restart,  normal  synchronous  operation,  system  backup/ 
recovery  and  system  reconfiguration. 

This  paper  discusses  the  system  protocol  requirements 
for  a data  transfer  system.  The  DAIS  protocol  and  how  it 
affected  the  multiplex  hardware  design  will  also  be  described. 
The  current  status  of  the  DAIS  Multiplex  Hardware  is  also 
presented. 

WHY  PROTOCOL 


The  purpose  of  system  control  procedures  is  to  define 
system  operational  flows  for  the  overall  system  architecture. 
The  detail  methodology  and  strategy  for  system  startup/restart, 
data  bus  message  protocol,  system  synchronization,  recovery 
strategy  for  detailed  message  transmission  errors  and  per- 
manent faults,  and  passing  of  system  command  and  control 
information  is  required  in  a system  control  procedure.  In 
other  words  the  system  control  procedure  defines  the  functions 
to  be  performed  by  the  elements  of  the  system  to  establish 
system  control. 

In  developing  a system  control  procedure,  several  ground- 
rules  and  assumptions  are  necessary  in  order  to  establish  a 
baseline  design.  First  the  classes  of  error  and  failure 


99 


w 


conditions  need  to  be  defined.  The  bus  message  errors,  mux 
hardware  errors,  software  caused  errors,  and  power  transients 
that  the  system  will  respond  to  have  to  be  decided  upon.  Next 
the  recovery  approach  to  these  errors  or  failures  has  to  be 
spelled  out.  How  many  errors  will  the  system  handle  at  one 
time  and  when  the  system  should  respond  to  a detected  error 
or  failure  affects  the  overall  complexity  of  the  control 
procedures  and  thus  the  hardware. 

Recovery  from  power  transients  fall  into  two  areas. 

First  there  are  transients  from  normal  electrical  system 
operation  such  as  switching  of  equipment  loads,  engine  speed 
changes,  and  power  bus  switching.  Then  there  are  the  tran- 
sients from  the  abnormal  electrical  system  operation  such  as 
momentary  loss  of  control  of  the  electrical  system.  In  the 
control  procedures,  assumptions  have  to  be  made  concerning 
the  capability  of  the  hardware  to  operate  through  and  recover 
from  these  transients. 

Certain  mission  avionic  functions  are  specified  as 
mission  critical  and  special  recovery  and  backup  procedures 
are  required  for  these  functions.  These  procedures  along 
with  the  hardware  provide  the  system  with  the  capability  to 
recover  from  a system  failure  and  then  allow  completion  of 
the  mission  after  reconfiguration. 

Finally  the  types  of  bus  message  retrys  have  to  be  defined. 
Certain  bus  messages  can  automatically  be  retried.  Other  messages 
may  cause  degradation  of  the  subsystem  by  repeated  reception  of 
the  same  message.  An  example  of  this  situation  is  a message 
containing  gyro  torqueing  pulses  which  would  degrade  the  per- 
formance or  cause  failure  of  the  inertial  measurement  system 
if  repeated. 

DAIS  PROTOCOL 


DAIS  is  an  avionics  system  architecture  which  consists  of 
multiple  federated  processors  that  communicate  between  each 
processor  and  the  other  system  elements  (sensors,  weapons,  and 
controls  and  displays)  through  a standardized  multiplex  data 
bus  system.  This  system  architecture  is  flexible  to  accommodate 
a wide  variety  of  avionic  configurations,  missions,  and  sensors, 
and  provides  redundancy  to  improve  availability.  This  is 
achieved  by  defining  functionally  standardized  core  elements 
which  can  be  integrated  in  various  mixes  and  configurations 
to  accomplish  the  specific  mission  requirements.  The  DAIS 
system  architecture  is  depicted  in  Figure  1.  The  Master 
Executive  provides  a centralized  control  point  for  system 
operation;  however,  this  control  point  may  be  relocated 
for  system  reconfiguration. 
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DUAL  REDUNDANT  DATA  BUS 


1 ' 


The  DAIS  core  elements  can  be  described  functionally  as 
follows : 

a.  DAIS  processors  are  general  purpose  computers  de- 
signed for  airborne  use.  The  number  of  DAIS 
processors  required  is  determined  by  the  mission 
requirements  and  the  mission  software  to  be  loaded. 

The  DAIS  processors  are  arranged  in  a federated 
processor  configuration  interconnected  through 

the  DAIS  multiplex  system. 

b.  DAIS  multiplex  provides  command  and  data  information 
transfer  between  the  DAIS  processors  and  the  sub- 
systems (sensors  and  weapons) , and  the  controls  and 
displays.  It  consists  of  Bus  Control  Interface  Units 
(one  for  each  DAIS  processor) , Remote  Terminal  Units 
(which  interface  the  subsystems  to  the  data  bus) , 
and  the  redundant  multiplex  data  buses.  The  System 
Control  Procedures  define  the  bus  protocol,  and  bus 
error  and  core  element  failure  management.  This 
system  is  a time  division  multiplex  (TDM)  system 

and  a command/response  system  with  one  BCIU,  under 
control  of  the  Master  Executive;  controlling  bus 
traffic  on  only  one  bus  at  any  given  time.  The 
other  bus  is  provided  for  redundancy  considerations. 

c.  DAIS  Controls  and  Displays  is  an  integrated  set  of 
state-of-the-art  equipment  which  is  designed  to 
provide  flexibility  to  accommodate  changes,  redundancy 
where  required,  and  designed  for  system  management  by 
one  pilot. 

d.  Mission  Software  will  reside  in  the  memory  of  the  DAIS 
processors.  Two  separate  computer  programs  have  been 
identified  to  support  the  DAIS  architecture.  These 
are  designated  the  Operational  Test  Program  (OTP)  and 
the  Operational  Flight  Program  (OFP) . 

The  sensor,  weapon  and  communication  subsystem-s  are  inter- 
faced to  the  DAIS  processors  through  the  Remote  Terminals  and 
the  subsystem  configuration  is  dependent  on  the  mission  require- 
ments . 

The  System  Control  Procedures  define  the  total  DAIS 
operation  and  consist  of  the  following  system  operational 
modes : 

1.  System  Startup/Restart  Operation 

2.  Pre-Flight/Post-Flight  Test  Operations 
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3.  Normal  System  Operations 


• Bus  Protocol:  Synchronous  and  Asynchronous 

Bus  Message  Operations,  and  Minor  Cycle 
Synchronization 

• Mission  Application  Tasks 

• Error/Failure  Management 

• Monitor  Management  Functions 

• Configuration  Management  Functions 

• Power  Management  Functions 

4.  System  Backup/Recovery  Operation 

5.  System  Reconfiguration  Operation 

This  paper  will  address  normal  system  operations  and 
in  particular  bus  protocol  and  error/failure  management. 

During  normal  system  operation,  the  Master  BCIU  and  the 
Master  Processor  operate  together  as  the  bus  controller.  The 
functions  which  are  performed  during  normal  system  operations 
are: 

1.  Minor  cycle  synchronization 

2.  Bus  message  operation  (bus  protocol) : 
synchronous,  asynchronous,  and  mode 
bus  message  operation 

3.  Mission  application  tasks 

4.  System  error/failure  management 

5.  Monitor  management  function 

6.  Configuration  management 

7.  Power  management 

Minor  cycle  synchronization  is  required  to  provide  a time 
reference  for  the  processors. 

The  Master  Executive  performs  minor  cycle  synchronization 
when  the  minor  cycle  clock  expires  by: 

a.  Checking  synchronous  bus  messages  for  completion. 

b.  Increments  minor  cycle  count  and  transmits  minor 
cycle  mode  commands  to  remote/monitor  processors. 
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c.  If  synchronous  bus  messages  were  not  completed, 
extends  period  for  one  more  minor  cycle  time 
period  and  completes  synchronous  bus  messages. 

d.  If  a minor  cycle  synchronization  failure  is  indicated, 
tabulates  failure  and  attempts  to  complete  all  minor 
cycle  commands.  Minor  cycle  synchronization  failure 
analysis  is  performed  after  all  minor  cycle  commands 
have  been  attempted. 

e.  Upon  successfully  completing  minor  cycle  synchroni- 
zation and  setting  up  the  synchronous  bus  message 
table,  synchronous  bus  message  transmission  is 
initiated.  The  Local  Executive  checks  for  correct 
minor  cycle  number  and  sets  up  the  synchronous  bus 
message  tables  for  the  next  minor  cycle. 

Minor  cycle  synchronization  is  mechanized  in  the  DAIS  system 
through  the  use  of  the  Master  Function  Interrupt  Mode  Command. 

The  Remote  Processor  interprets  the  mode  data  as  the  minor 
cycle  number 

Mode  command  operations  are  initiated  as  a result  of 
various  requests  from  the  Master  Executive  such  as  message 
error  analysis,  power  management,  minor  cycle  synchronization, 
etc.  The  Master  BCIU  transmits  the  mode  command,  and  the 
addressed  RT  or  Remote  BCIU  responds  to  the  mode  command  by 
performing  the  requested  operation  or  providing  the  response 
(e.g.  BIT  WORD,  Last  Command  Word,  etc.).  Table  1 identifies 
the  DAIS  Mode  Commands.  The  Mode  Command  Operations  are 
defined  in  the  system  flow  charts.  Mode  Commands  impacted 
the  Master  Executive  Software,  the  BCIU  y-code,  RT  y-code 
and  the  nubmer  of  registers  in  the  BCIU  and  RT. 

$ 

Bus  traffic  is  made  up  of  both  synchronous  and  asynchronous 
transmissions.  The  synchronous  bus  traffic  is  controlled  by  a 
predefined  bus  command  list.  Bus  traffic  may  occur  between 
the  bus  controller  and  a terminal,  or  between  two  terminals. 

Bus  messages  are  made  up  of  two  or  more  words.  Word  types 
are  command,  status  (response)  and  data.  The  bus  controller 
generates  message  sequences  which  exercise  system  control  and 
transfers  data  and  status  information  between  the  terminals 
as  required. 

The  synchronous  bus  message  operations  define  the: 

1.  Initialization  and  operation  of  BCIU  for  message 
transmission  operations. 

2.  Responses  to  BCIU  interrupt  conditions  at  master, 
monitor  or  remote  processor. 
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- Valid  (Status)~r>CIU  in  Master 
Mode  shall  expect  only  a Status 
h’o r.i  Response  for  all  undefined 
Mode  Op-?rations. 


3.  Responses  to  status  word  conditions  at  master 
processor. 

4.  Responses  of  remote  terminal  to  synchronous  message. 

Synchronous  operations  are  controlled  by  the  Executive 
Master  Scheduler.  Anamolous  conditions  in  the  synchronous 
bus  traffic  are  interpreted  by  the  BCIU  and  presented  to  the 
processor  via  a dedicated  priority-encoded  interrupts. 

Asynchronous  bus  operation  is  required  for  inter-processor 
task  communication,  cockpit  switches,  and  to  indicate  system 
problems.  Asynchronous  bus  message  traffic  is  initiated  in 
one  of  three  ways: 

1.  An  application  task  requests  an  executive  service  to: 

a.  Write  a compool 

b.  Set  an  event 

c.  Invoke  a task 

d.  Cancel/terminate  tasks 

and  the  compool/event/task  is  located  in  other  proc- 
essors. To  effect  the  required  executive  service, 
an  asynchronous  message (s)  must  be  set  to  the  other 
processor  (s) . 

2.  An  application  task  requests  that  a particular  message 
(compool  data)  be  transmitted  to  a specified  terminal 
at  a specific  future  time.  Two  asynchronous  messages 
may  be  required.  If  the  application  task  is  not  located 
in  the  master  processor,  one  asynchronous  message  is 
required  to  transfer  the  "critically  timed"  message 

to  the  master  executive  and  to  identify  the  terminal 
to  which  the  message  is  to  be  sent  and  the  time  at 
which  transmission  is  to  occur.  A second  asynchronous 
message  is  required  to  transmit  the  "critically  timed" 
message  from  the  master  to  the  specified  terminal. 

3.  An  asynchronous  message  transmission  is  requested  by 
an  RT  (initially  by  a subsystem  connected  to  an  RT) ; 
the  master  executive  receives  the  request  and  controls 
the  transmission  of  the  requested  message.  The  request 
is  made  to  the  Master  BCIU  through  the  status  word. 

This  operation  requires  a status  word  and  mode  codes. 

It  required  that  the  BCIU  be  able  to  interrupt  the 
processor. 

Error  control  is  required  because  of  the  normal  bit  error 
rate  on  the  bus,  hardware  failures  and  power  transients. 


The  Master  Processor  and  BCIU  per formsy stem  error/failure 
management  by: 

a.  Monitoring  message  sequence  to  determine  successful/ 
unsuccessful  completion. 

b.  Repeating  the  messages  (Class  I retry)  first,  on  the 
same  bus,  and  then  on  the  alternate  bus  if  message 
retry  is  indicated. 

c.  Performing  Class  II  retry  if  required  for  a message. 

d.  Analyzing  detected  message  error,  terminal  failure 
status  information,  and  message  sequence  history 
to  detect  and  isolate  failure  to  the  core  elements 
(RT,  BCIU,  Processor,  Control  and  Display)  or  re- 
dundant elements  of  the  RT,  BCIU,  or  bus. 

e.  Request  self- test  be  performed  when  core  element  is 
suspected  as  failed,  and  declare  core  elemnt  as 
failed  if  self-test  is  not  successful. 

f.  Report  declare  failures  to  configuration  management, 
which  modifies  the  synchronous  and  asynchronous  bus 
traffic  accordingly  and  also  notifies  the  applications 
software  (the  configurator)  for  appropriate  action. 

Error/failure  managements  requires  the  use  of  mode  commands, 
retrys  and  processor  interrupts. 

There  are  four  basic  errors/failure  types.  These  include 
status  word  errors,  message  errors,  data  errors  and  terminal 
failures.  The  first  three  require  that  one  of  three  types  of 
retrys  be  initiated.  The  fourth  requires  an  interrupt  to  the 
processor. 

A Class  I Retry  is  used  when  the  repeated  transmission  of 
a message  will  not  affect  the  sybsystem. 

Class  II  Retry  is  performed  when  repeated  transmission  of 
same  message  to  a Remote  Terminal  could  cause  degradation  in 
subsystem  performance.  The  Master  Executive  will  first  request 
transmission  of  a mode  command  to  obtain  from  the  RT  the  Last 
Command  received  by  that  RT.  If  it  is  not  the  same  as  the 
last  Bus  Message  transmitted,  the  same  Bus  Message  shall  be 
retransmitted  to  that  RT.  If  the  Last  Command  is  the  same  as 
the  last  Bus  Message  transmitted  and  no  message  errors  are 
reported,  the  Master  Executive  will  continue  with  the  scheduled 
Bus  Messages. 
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A Class  III  Retry  is  used  when  the  last  message  consisted 
of  more  than  one  transmission.  If  retry  is  indicated,  the 
BCIU  will  retransmit  the  last  message  sequence. 

Status  word  errors  includes  no  response,  parity  error  and 
format  errors.  If  there  was  an  error  in  the  last  message,  the 
RT  does  not  transmit  the  status  word.  The  only  exception  is 
an  invalid  mode  code.  If  a Class  I Retry  ii>  indicated,  the 
message  will  be  retransmitted.  If  a Class  II  or  Class  III 
Retry  is  indicated  the  Built-In-Test  will  be  requested  to 
determine  if  there  was  a message,  data  or  terminal  error. 

The  Master  BCIU/Processor  monitors  for  message  errors  and 
if  message  error  condition  is  detected  shall: 

1.  Retry  the  message  on  the  same  bus  if  retry  is 
indicated. 

2.  Retry  the  message  on  the  alternate  bus  if  no 
redundant  element  failure  is  indicated. 

3.  Perform  Class  II  retry  if  indicated. 

4.  Initiate  redundant  element  or  terminal  failure 
analysis  if  retry  of  the  message  is  not  successful. 

Upon  leceiving  a message  error  response  after  an  asynchronous 
message  transmission,  the  Master  Executive  shall: 

1.  Determine  if  the  transmitter  or  receiver  was  the 
suspected  cause  of  the  error  condition. 

2.  Request  a status  word  from  the  suspected  terminal 
including  retry  of  this  mode  command  on  one  side 
of  the  data  bus  and  then  on  the  other  if  required. 

3.  Realigning  the  asynchronous  queue  and  retransmitting 
the  asynchronous  message,  if  the  status  word  was 
successfully  received  from  the  suspected  terminal. 

As  a result  of  a failure  to  successfully  complete  a bus 
message,  the  Master  Executive  shall: 

1.  Determine  if  a Master  BCIU  failure  is  indicated 
by  transmitting  a mode  command  to  another  remote 
BCIU. 


... 


2.  Initiating  BCIU  self-test  or  request  terminal  self- 
test be  performed. 


¥ 


3.  Declare  the  BCIU  or  terminal  as  failed  if  self- 
test is  not  successfully  completed. 

If  a "Busy"  indication  is  received  from  a remote  or 
monitor  BCIU/Processor , the  Master  Executive  shall  initiate 
Busy  Override  Operations. 

The  Master  Executive,  upon  receiving  a terminal  failure 
indication  in  the  status  word,  shall  request  BIT  Word  from 
^ the  terminal.  The  Master  Executive,  upon  decoding  the  BIT 
Word,  shall: 

1.  Initiate  self-test  of  the  terminal  if  a redundant 
element  or  terminal  failure  is  indicated. 

2.  If  self-test  is  not  successful,  the  redundant 
element  or  terminal  is  declared  a failure  and 
configuration  management  is  initiated. 

3.  Respond  to  element  power  recovery  indication  by: 

a.  Repeating  the  message,  if  a remote  terminal 
or  BCIU. 

b.  Performing  power  transient  recovery  operations, 
if  a remote  or  monitor  processor  indicates  that 
a power  transient  has  occured,  causing  the  loss 
of  system  synchronization. 

The  Master  Executive  will  tabulate  suspected  redundant 
element  failures  and  return  to  complete  the  synchronous  or 
asynchronous  message  retrys.  The  Master  Executive  will 
determine  if  the  "suspect"  redundant  element  failure  is  the 
Master  BCIU/BCIU  or  a redundant  element  in  a terminal  or 
Remote/Monitor  BCIU.  ^fter  exceeding  a threshold  of  sus- 
pected failures  for  a redundant  element,  self-test  will  be 
initiated.  If  self-test  is  not  successfully  completed,  the 
redundant  element  is  declared  a failure  and  configuration 
management  is  initiated. 

Periodically,  self-test  of  each  RT  and  BCIU  will  be 
initiated  by  the  Master  Executive  on  both  redundant  element 
(A&B)  sides.  Upon  successfully  completing  self-test,  any 
"suspect"  redundant  element  failures  will  be  cleared. 

Error/failure  analysis  and  recovery  require  that  the 
BCIU  interpret  the  status  (or  lack  of)  response  for  all 
normal  bus  errors  and  terminal  failures.  The  BCIU  must  then 
present  the  results  to  the  Processor  in  a logical  and  ordered 
sequence.  The  DAIS  BCIU  provides  dedicated  priority  encoded 
interrupts  to  signal  anomolous  conditions  to  the  Processor, 
and  a separate  input/output  interface  to  read  hardware  status. 
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DAIS  MULTIPLEX  HARDWARE 


The  DAIS  Multiplex  Hardware  consists  of  Remote  Terminals, 
Bus  Control  Interface  Units  and  Testers.  The  equipment  is 
being  built  to  MIL-STD-1553A.  The  multiplex  system  can 
accommodate  a varying  mission-oriented  avionics  configuration 
by  qu:  k replacement  of  on-board  avionics  subsystems. 

The  remote  terminal  provides  the  primary  mechanism  for 
interfacing  air  vehicle  subsystem  equipments  with  the  DAIS 
core  elements.  The  RT  also  interfaces  certain  DAIS  core 
elements  with  other  DAIS  core  elements.  The  RT  transmits  and 
receives  data  on  the  bus,  performs  message  validation  and  built 
in  test.  The  RT  also  receives  data  from  the  subsystems  and 
converts  it  to  the  proper  data  bus  format  and  converts  data 
from  the  bus  into  the  proper  format  for  the  subsystem. 

The  major  components  of  the  RT  are  shown  in  Figure  1. 

The  multiplex  terminal  unit  (MTU)  is  the  device  that  interfaces 
to  the  data  bus.  This  MTU  transmits  and  receives  information 
between  the  data  bus  and  the  timing  and  control  unit  (TCU) , 
under  control  of  the  TCU.  The  unit  employs  common  mode 
rejection  and  filtering  to  minimize  noise  susceptibility. 
Validity  checks  include  sync,  parity,  manchester  validity 
and  bit  count. 

The  timing  and  control  unit  (TCU)  is  the  device  that 
performs  all  of  the  timing,  control,  buffering,  decoding 
and  checking  required  to  receive  information  from  the  data 
bus  and  reflect  that  information  as  outputs  from  the  RT,  as 
well  as  to  accept  inputs  to  the  RT  and  reflect  their  inputs 
as  information  on  the  data  bus.  The  TCU  performs  these 
functions  based  upon  commands  received  from  the  data  bus. 

In  order  to  have  the  capability  to  add  and  delete  mode  codes 
and  to  provide  greater  flexibility,  a micro-processor  was 
designed  into  the  TCU.  To  support  the  mode  code  implementation 
sixteen  registers  were  required  to  store  such  data  as  the  last 
command,  BIT  word,  etc. 

Interface  modules  (IM's)  provide  the  scaling,  signal 
conditioning  and  formatting  for  both  signals  coming  from 
the  data  bus  and  from  the  avionic  subsystems.  The  IM's 
have  a standard  TCU  interface  and  thus  can  be  placed  in  any 
slot  in  the  RT.  This  allows  you  to  personalize  the  IM  mix 
for  each  RT.  As  shown  in  Table  2,  interface  modules  are 
provided  for  all  classes  of  electrical  interfaces  now  found 
in  aircraft. 

The  RT  is  configured  in  two  3/4  ATR  box  sizes;  a short 
RT  that  is  12.5  inches  long  and  a long  that  is  19.5  inches 
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long.  The  short  RT  contains  spaces  for  eight  IM's,  two  MTU 
pages,  and  6 TCU  pages.  The  long  RT  contains  spaces  for 
16  IM's,  two  MTU  pages,  and  6 TCU  pages.  Both  RT's  are  dual 
redundant  in  the  MTU  and  TCU. 

The  Bus  Control  Interface  Unit  (BCIU)  provides  the  inter- 
face, control  and  data  transfer  function  required  to  connect 
a Processor  with  two  multiplexed  data  buses.  The  BCIU  is 
directed  to  operate  in  a mode  by  its  interfacing  processor. 

The  following  are  the  modes  in  which  the  BCIU  is  capable  of 
operating: 

Remote  Mode,  providing  transfer  of  data  in  both  direction 
between  the  Processor  and  either  of  two  data  buses,  based  upon 
commands  received  from  either  of  the  data  buses,  providing 
status  replies  on  the  appropriate  data  bus  in  response  to 
commands,  and  special  internal  operations  and  interrupts  to 
the  associated  processor  upon  receipt  of  certain  special 
commands  on  the  data  buses. 

Master  Mode  providing  control  of  the  two  data  buses  based 
upon  instructions  fetched  from  the  memory  of  the  Processor 
through  the  Direct  Memory  Access  (DMA)  Channel  by  the  BCIU. 

This  Control  Mode  results  in  the  BCIU  issuing  bus  commands 
to  other  devices  on  the  data  buses,  participating  in  data 
transfers  on  the  buses  (when  the  instruction  dictates  it) , 
checking  status  responses  from  devices  on  the  data  buses, 
checking  formats  of  the  data  bus  operation,  and  reporting 
of  error  conditions  to  the  Processor.  At  any  one  time,  there 
is  only  one  BCIU  in  the  Master  Mode,  in  any  one  data  bus  system. 

Figure  3 illustrates  the  Major  Components  that  comprise  a 
BCIU.  Each  Bus  Interface  Module  (BIM)  provides  the  interface 
fuunction  to  one  data  bus.  The  BIM  is  the  same  as  the  MTU  in 
the  RT.  These  modules  are  interchangeable. 

The  Processor  Interface  Module  (PIM)  provides  the  interface 
function  to  the  Processor.  The  changing  of  Processor  types  is 
accommodated  by  a redesign  of  only  the  PIM.  The  Bus  Control 
Module  provides  the  timing,  control,  instruction  decoding  and 
data  transfer  routing  required  to  implement  the  various  operation 
modes  defined. 

The  BCM  is  the  device  which  controls  the  operation  of  the 
BIMs  in  order  to  perform  data  bus  operations,  and  the  device 
which  controls  the  PIM  in  order  to  communicate  with  the  Proc- 
essor. The  method  in  which  the  BCM  performs  these  control 
functions  depends  upon  the  BCIU  operational  mode.  Essentially, 
the  BCM  is  the  control  device  which  implements  the  Master  and 
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Remote  operations.  The  BCM  contains  control  registers  that 
the  Processor  can  load  through  the  PIO  channel,  and  registers 
that  the  Processor  can  read  through  the  PIO  channel.  These 
PIO  operations  take  place  directly  and  require  no  action  by  the 
BCM.  The  PIO  operations  that  the  Processor  performs  determine 
the  BCM  state.  The  BCM  contains  the  registers,  selection  logic, 
comparison  logic,  and  control  sequences  required  to  transmit 
and  receive  words  with  the  BCM's,  read  and  write  words  through 
the  DMA  channel,  provide  DMA  addresses  for  the  DMA  operation, 
and  perform  bus  message  generation.  In  order  to  have  flexibility 
in  performing  these  functions,  a micro-processor  was  designed 
into  the  BCM. 


The  PIM  forms  the  communications  channel  between  the  BCM 
and  the  Processor.  The  PIM  accepts  control  and  information 
signals  from  the  BCM  and  performs  DMA  operations  with  the  Proc- 
essor's Memory  based  upon  these  signals.  The  PIM  also  accepts 
Interrupt  Request  signals  from  the  BCM  and  generates  interrupts 
to  the  Processor  based  upon  these  requests. 


All  DMA  operations  are  single  word  DMA  Read  or  Write 
perations  based  upon  a request  by  the  BCM.  When  the  PIM  is 
not  currently  performing  a DMA  operation,  and  it  detects  a 
pulse  on  the  DMA  Request  Line,  it  performs  either  a DMA  Read 
or  a DMA  Write  operation. 


The  BCIU  is  housed  in  a 3/4  ATR  box  that  is  12.5  inches 
long.  There  are  two  BIM  pages,  five  BCM  pages  and  two  PIM 
pages . 


There  are  three  pieces  of  DAIS  Multiplex  Test  Equipment; 
the  RT  Tester,  the  BCIU  Tester  and  the  System  Support  Facility. 
The  testers  can  be  divided  into  two  categories:  test  and  mainte- 
nance support,  and  demonstration  and  integration  support.  The 
equipment  is  required  to  provide  the  support  capabilities  for 
the  following  tasks: 


Performance  of  major  test  plan, 


Performance  of  major  component  interaction  test  plan. 


Performance  of  system  demonstration  and  acceptance 
test  plan. 


Testing  and  maintenance  of  the  multiplex  hardware. 


Aid  in  initial  system  integration. 


The  RT  tester  is  used  to  conduct  all  test  required  by 
the  RT  Major  Component  Test  Plan  and  the  RT  Major  Component 


Interaction  Test  Plan.  The  RT  tester  is  a manually  controlled, 
stand-alone  tester  that  simulates  inputs  to  MTU,  TCU,  IM  and 
power  supply  modules  and  monitors  the  outputs  of  these  modules. 

The  tester  can  also  function  as  a bus  controller  and  a bus 
monitor.  These  operational  modes  and  test  functions  are 
controlled  from  the  front  Danel. 

The  BCIU  tester  is  used  to  conduct  all  tests  required  by 
the  BCIU  Major  Component  Test  Plan  and  the  BCIU  Major  Component 
Interaction  Plan.  The  tester  is  a manually  controlled  stand- 
alone tester  that  simulates  inputs  to  the  bus  control  modules 
and  processor  interface  modules  and  monitors  the  outpus  of  these 
modules.  The  tester  provides  the  capability  of  troubleshooting 
failed  major  components  and  isolating  the  failure.  The  tester 
can  also  function  as  a bus  controller  and  as  a bus  monitor. 

The  system  support  facility  is  composed  of  one  PDP  11/40 
and  paripherals,  one  RT  support  I/O  and  one  BCIU  support  I/O. 

The  tester  has  the  hardware  and  software  to  perform  the  following 
functions : 

• Data  bus  controller/BCIU 

• Remote  terminal 

• DAIS  processor 

• Subsystem  interfacing 

• Bus  monitor. 

The  support  software  package  permits  the  tester  to  perform  sys- 
tem checkout,  integration  and  monitoring.  Application  software 
allows  the  tester  to  perform  a system  demonstration  and  acceptance 
tests  on  RT's  and  BCIU's. 

Six  BCIU's  and  the  BCIU  Tester  have  been  received  and  are 
working.  The  first  RT's  and  the  RT  tester  are  due  in  November 
76. 


CONCLUSION 


System  control  procedures  are  critical  and  directly  affect 
the  design  of  the  hardware.  Multiplex  hardware  built  to  1553A 
will  be  electrically  compatible  but  the  procedure  to  control 
the  hardware  could  be  vastly  different.  The  line  between  a 
standard  and  a specification  is  fine  but  the  standard  has  to 
be  detailed  enough  to  allow  equipment  built  to  it  to  work 
together.  MIL-STD-1553A  allows  mode  codes  but  does  not  define 


any.  The  status  code  field  of  the  status  word  is  left  for  use 
by  the  system  designer.  Thought  needs  to  be  given  to  the  need 
for  including  in  1553A  the  standard  part  of  a control  procedure. 
With  a standard  Protocol/Control  procedure,  interchange  of  multi 
plex  hardware  between  different  aircraft  would  be  a giant  step 
closer. 
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ABSTRACT 

The  AFFDL/DAIS  Program  is  developing  a digital 
flight  control  system  simulation  using  the  DAIS  hard- 
ware. The  A-7D  Digital  Multimode  Flight  Control 
System  is  being  used  as  a baseline.  The  multiplex 
data  bus  architecture  of  the  DAIS  flight  control  sys- 
tem is  described  in  detail.  (Fail-Op)2  capability 
(for  fly-by-wire  operation)  is  attained  through  quad 
redundancy,  using  majority  voting  (lower  median  select) 
without  use  of  self-test  or  in-line  monitoring  for 
in-flight  failure  detection  and  fault  isolation.  The 
asynchronous  operation  of  redundant  channels  and  the 
requirement  for  operation  in  the  presence  of  failure 
of  the  avionics  system  dictate  special  purpose  inter- 
faces with  the  avionics  system,  the  pilot,  and  within 
the  flight  control  system.  The  interface  to  the  rest 
of  the  avionics  is  an  asynchronous,  double-buffered 
interface  that  passes  data  in  each  direction  as 
available  in  the  transmitting  channel.  Interchannel 
communication  is  used  among  flight  control  channels 
to  prevent  channel  mode  disagreements  and  to  equalize 
integrator  drift.  The  pilot  has  a special  dedicated 
control  panel  to  handle  redundancy  and  failure  recycle 
independent  of  other  avionics  systems.  Safety  of 
flight  is  addressed  in  the  presence  of  failure  of  these 
interfaces . 
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INTRODUCTION 

In  order  to  demonstrate  a coherent  solution  to  the 
problems  of  proliferation  of  avionics  and  rising  costs 
of  avionics  systems,  the  Air  Force  has  instituted 
the  Digital  Avionics  Information  System  (DAIS)  advanced 
development  program.  The  objectives  of  DAIS  include 
the  development  of  a set  of  standardized  hardware  and 
software  modules  which  can  be  configured  for  use  in  a 
broad  spectrum  of  aircraft  applications,  and  the  inte- 
gration and  demonstration  of  these  modules  in  a hot 
bench  environment.  These  modules  include  computers, 
multiplex  data  bus  hardware  (built  to  implement  a 
MIL-STD-1553A  data  bus),  control/display  hardware,  and 
software  modules. 

The  Air  Force  Flight  Dynamics  Laboratory  has  been 
tasked,  in  part,  with  the  demonstration  of  these  modules 
configured  as  a flight  control  system  for  a typical 
modern  high-performance  f ighter/close-air  support  air- 
craft. The  objective  of  this  portion  of  the  AFFDL/DAIS 
program  is  to  demonstrate  the  feasibility  of  construct- 
ing a flight  control  system  for  either  control 
augmentation  or  fly-by-wire  applications  out  of  modules 
common  to  the  avionics  system,  and  to  evaluate  the 
performance  and  safety-of-flight  aspects  of  this  system. 

DAIS  FLIGHT  CONTROL  SYSTEM  ARCHITECTURE 

The  DAIS  flight  control  system  is  organized  as  a 
multiplex  data  bus  as  shown  in  Figure  1.  In  a simplex 
or  single-channel  configuration,  it  has  a single 
computer  acting  as  the  bus  controller  and  executing  the 
flight  control  algorithm,  and  three  remote  terminals 
(RTs)  connected  to  various  sensors  and  actuators,  one 
each  in  the  forward,  midship  and  aft  avionics  bays.  The 
inner-loop  sensors  (rate  gyros  and  accelerometers)  are 

attached  to  the  midship  terminal  via  a direct  analog  j 

input  interface;  the  analog-to-digital  converters  are 
centralized  in  each  remote  terminal.  Pilot  commands 
from  the  stick  and  pedals  and  trim  discretes  are  con- 
nected to  the  forward  remote  terminal.  The  aileron 
commands  emit  from  the  midship  RT  and  the  stabilator 
and  rudder  commands  from  the  aft  RT. 

In  the  full  simulation,  attitude  information  and 
air  data  (true  airspeed,  altitude)  come  from  the 
avionics  system  (which  is  actually  being  simulated  on 
a PDP-11)  into  the  forward  remote  terminal  through  a 
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serial  digital  interface.  Also  passing  through  this 
interface  are  pilot  mode  request  discretes,  computer 
mode  engagement  discretes,  and  failure  data  not  criti- 
cal to  safety-of-flight  (which  is  transferred  to  the 
DAIS  Integrated  Test  System  (DITS)  in  the  Avionics 
Simulation  Computer).  Various  discretes  relating  to 
flight  control  system  status  are  also  transferred  over 
the  data  bus.  These  include  Spin  Motor  Rotation 
Detector  (SMRD)  and  torquer  commands  for  the  gyros, 
servo  engage  command  and  solenoid  logic  status  discretes 
for  each  actuator,  and  channel  status  from  the  hardware 
voters  (discussed  below).  The  dedicated  control/display 
panel  (attached  to  the  forward  RT)  presents  flight 
critical  failure  status  information  on  each  channel  to 
the  pilot  and  accepts  reset  discretes  from  him.  In  the 
redundant  simulation,  the  interchannel  interface  will 
be  connected  to  the  forward  RT. 

The  flight  control  system  is  being  built  with  two 
sets  of  hardware.  Hands-on  experience  is  now  being 
acquired  with  the  Hardware  Architecture  Simulation  (HAS) 
which  contains  two  channels  of  flight  control,  consist- 
ing of  in-house  designed  and  built  remote  terminals, 
bus  control  interface  units,  and  cockpit  displays. 

PDP-11/40 's  are  used  for  the  flight  control  computations 
and  as  bus  controllers,  and  all  flight  control  coding  is 
being  done  in  assembly  language.  The  airframe  is  simu- 
lated on  two  SD-80  analog  computers.  The  cockpit  contains 
primarily  CRT's  driven  by  RAMTEK  Video  Display  Systems 
and  multifunction  keyboards  driven  by  UDC-ll's,  with  the 
entire  system  driven  by  a PDP-11/50,  programmed  in 
assembly  language  and  Fortran. 

The  DAIS  Flight  Engineering  Facility  (FEF),  shown 
in  Figure  2,  will  be  built  with  contractor-supplied 
hardware  (from  the  DAIS  program).  AN/AYK-15  processors 
(Westinghouse) , BCIU's  and  RT's  (IBM),  and  control/dis- 
play hardware  (Hughes  Aircraft)  will  be  integrated 
on-site  into  the  full  simulation.  The  flight  control  and 
control/display  software  will  be  written  in  J-73/1  (Jovial). 
The  avionics  simulation  will  be  hosted  on  PDP-11/40.  The 
airframe  equations  of  motion  will  be  simulated  on  a 
PDP-11/34. 

The  flight  control  algorithm  is  copied  from  the 
A-7D  Multimode  Digital  Flight  Control  System  (DFCS)  Pro- 
gram. It  is  executed  in  ten  major  frames  per  second 
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as  shown  in  Figure  3. 

Each  major  frame  con- 
tains eight  minor  frames, 
each  12.5  milliseconds 
long.  In  a given  minor 
frame,  the  sensors 
required  for  that  frame's 
computations  are  sampled 
and  data  collected  by  the 
computer  through  the  data 
bus.  When  all  data  is  in 
memory,  the  flight-control 
algorithm  is  performed. 
Finally,  the  actuator  com- 
mands are  transmitted  to 
the  appropriate  remote 
terminal,  and  the  processor 
waits  for  the  beginning  of 
the  next  minor  frame. 


OUTPUT  Tire 
Tlh€ 

FIGURE  3.  FLIGHT  CONTROL  ALGORITHM  TIMING 


MIL-F-9490D  imposes  a requirement  on  aircraft  loss 
due  to  failures  in  the  flight  control  system,  that 

Q^SxlO  /flight  hour'.  To  meet  this  requirement,  the 
imposition  on  the  multiplex  and  computer  electronics  was 

specified  as  Qfapqure‘1-*-x10  ^ Per  flight  hour.  To  meet 

this  requirement,  the  DAIS  FEF  will  contain  four  identi- 
cal channels  of  flight  control  electronics.  No  advanced 
redundancy  management,  state  estimation,  or  sensor 
orientation  techniques  will  be  used,  since  they  are  not 
a part  of  the  DAIS  program.  Built-in  test  is  only  used 
for  maintenance,  and  neither  in-flight  self-test  nor 
in-line  monitoring  are  used  for  fault  detection.  A sys- 
tem designed  using  current  techniques  of  analytical 
redundancy  and  fault  isolation  might  well  meet  the  failure 
rate  requirement  with  a triplex  system  or  with  mixed 
levels  of  redundancy  for  various  components.  Figure  4 is 
typical  of  the  complexity  of  cross-strapping  required  at 
a single  remote  terminal  for  a single  sensor  for  the  quad 
redundant  FEF.  (In  this  case,  a quad-redundant  rate  gyro 
is  shown . ) 
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The  (fail-op)  requirement  is  being  satisfied  for 
the  A-7D,  in  order  to  evaluate  a quad-redundant  system 
for  performance  and  safety-of-flight  qualities.  Even 
though  the  A-7D  Control  Augmentation  System  (CAS)  is 
fail-safe,  these  qualities  can  be  evaluated  as  though 
the  DAIS  simulation  were  fly-by-wire. 

Simple  comparison  monitoring  is  being  used  for 
failure  detection,  and  lower-median  select  voting  is 
implemented  for  all  sensors,  and  also  for  channel  out- 
puts to  actuators.  Voting  planes  exist  between  sensors 
and  computers,  and  also  between  multiplex  hardware  and 
actuators,  as  shown  in  Figure  4.  Sensors  are  voted  and 
compared  in  software,  and  actuator  commands  in  hardware. 

A Digital  Hardware  Voter/Monitor  (DHVM)  has  been 
developed  that  selects  the  lower  median  of  four  signals, 
the  median  of  three  if  one  is  declared  failed,  and 
lower  in  absolute  magnitude  of  two,  if  two  are  declared 
failed. ^ it  compares  inputs  to  the  selected  channel 
and  declares  a failure  if  a miscompare  exceeds  a preset 
tolerance  for  a certain  period  of  time.  Each  of  the 
four  multiplex  systems  supplies  an  input  to  each  DHVM 
for  each  actuator.  Each  primary  actuator  has  four 
secondary  actuators  which  are  force-summed.  Each  secon- 
dary actuator  has  a dedicated  DHVM.  Four  copies  of  each 
pilot  command  variable  (e.g.,  four  strain  gauges  for 
pitch  stick  force),  and  each  sensor  are  connected  to  an 
RT  on  each  multiplex  data  bus.  Logic  identical  to  that 
of  the  DHVM  is  implemented  in  software  for  the  sensors 
and  pilot  commands. 

The  four  channels  of  flight  control  processing  are 
not  synchronized.  This  immensely  simplifies  the  problem 
of  preventing  single-point  failures  since  fail-opera- 
tional frame  synchronization  requires  fairly  complicated 
computer-to-computer  communications.  Asynchronous 
operations  let  us  "get  away"  with  an  interface  at  the 
remote  terminals.  There  is  no  master  clock... if  any 
channel  fails,  it  is  noted  but  does  not  interfere  with 
the  operation  of  the  rest  of  the  systems. 

The  offsetting  cost  of  asynchronous  operation  is 
that  the  channels  do  not  have  identical  inputs  or  out- 
puts, and  the  actuator  commands  are  not  updated 
simultaneously.  The  problem  of  errors  inherent  in  asyn- 
chronous operation  with  no  failures  present  is  accept- 
able and  can  be  lived  with.  Specifically,  the  comparison 
monitor  disagreement  due  to  asynchronism  does  not  appear 
to  be  worse  than  the  disagreement  among  analog  channels 
with  component  tolerance  error  buildup.3 
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Another  problem  of  asynchronous  operation  is  that 
since  integrators  will  not  have  identical  inputs,  and 
will  have  different  sampling  times  and  finite  word 
lengths,  they  will  tend  to  drift  slowly  with  respect  to 
each  other.  This  problem  will  be  overcome  by  exchang- 
ing integrator  outputs  across  the  flight  control  channels, 
asynchronously.  The  integrator  outputs  are  then  voted 
for  input  to  the  next  iteration  of  integration.  If  the 
interconnection  from  one  channel  fails,  its  output  would 
be  declared  failed  and  the  other  channels  would  track 
loosely  through  second  order  coupling.  Since  integrator 
drift  is  very  slow,  this  would  accomplish  the  desired 
objective . 

Mode  engagement  discretes  are  also  passed  across  the 
interbus  interface  to  verify  that  all'  channels  are 
engaged  in  the  same  mode.  Mode  engagement  is  voted  since, 
if  different  channels  were  in  different  modes,  they  would 
issue  different  commands  and  declare  a channel  failed, 
even  though  the  failure  might  be  in  the  interface  to  the 
avionics  system. 


The  interface  unit  that  passes  data  between  the 
flight  control  channels,  shown  in  Figure  5,  is  built  with 


twelve  identical  interface  cards.  The  interface  card  is 
designed  to  operate  between  two  serial-digital  channels 
(as  defined  in  MIL-STD-155 3A) . The  interface  unit  con- 
sists essentially  of  six  sets  of  two  undirectional  cards, 
one  each  way  (each  card  operates  in  the  double-buffered 
fashion  shown  in  Figure  6).  No  busy  signal  is  needed  on 
the  input  and  data  is 
always  available  on 
request  on  the  output. 

The  time  history  at 
the  bottom  of  Figure  6 
is  typical  of  the  opera- 
tion of  a single 
asynchronous  interface 
card.  At  tin.  "i",  the 
input  channel  has  data, 
so  this  data  is  loaded 
into  Memory  B.  While 
loading  Memory  B,  there 
is  a request  for  data 
(at  time  "j")  so  Memory 
A is  unloaded.  At  "k" , 
the  loading  of  B is 

complete.  After  A is  finally  unloaded,  the  switches 
toggle  so  the  next  unload  will  be  B and  the  next  load 
will  be  into  A.  Each  flight  control  channel  updates  the 
other  three  channels  by  loading  data  into  the  interface 
cards  that  connect  to  the  other  channels  at  the  end  of 
the  appropriate  minor  frame.  Each  channel  reads  data 
from  the  interface  cards  that  connect  to  the  other  chan- 
nels at  the  beginning  of  the  appropriate  minor  frame. 


FIGOtt  t.  AS*NO*«NUft  SCBIAt 


AVIONICS  SYSTEM  INTERFACE 


In  the  final  configuration,  the  flight  control  sys- 
tem will  be  integrated  with  an  avionics  system  simulation 
as  shown  in  Figure  2.  In  order  to  make  the  flight 
control  system  operate  in  the  presence  of  two  failures, 
it  must  be  independent  of  the  avionics  system  (which  is 
not  redundant,  except  in  multiplex  communications  chan- 
nels, which  have  a standby,  redundant  bus).  Since  the 
flight  control  channels  are  all  asynchronous  with  respect 
to  the  avionics  system,  the  same  asynchronous  interface 
card  discussed  above  is  used.  The  avionics  interface  con- 
tains four  sets  of  asynchronous  interface  cards,  thus 
permitting  each  flight  control  channel  to  "talk"  asynchron 
ously  to  the  avionics  system.  That  is,  each  channel 
(flight  control  and  avionics)  reads  from,  and  writes  into, 
the  interface  at  the  appropriate  time  in  its  own  operation 
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Data  transferred  over  this  interface  to  the 
avionics  bus  includes  DAIS  Integrated  Test  System  (DITS) 
data  (sent  to  the  avionics  system  by  each  flight  control 
channel  for  in-flight  failure  monitoring/recording),  and 
mode  engagement  discretes.  Air  data  (such  as  true  air- 
speed) and  autopilot  data  (such  as  altitude  error, 
heading,  and  attitude),  and  mode  request  discretes  are 
transferred  from  avionics  to  each  flight  control  channel. 

If  the  avionics  system  or  the  interface  fails,  it 
becomes  impossible  for  the  pilot  to  control  mode  selec- 
tion, so  the  flight  control  channels  all  revert  to  a 
standard  backup  mode  which  is  the  basic  control  augmen- 
tation of  the  A-7D  (CAS  mode)  and  no  autopilot  modes  are 
possible.  If  the  entire  interface  fails,  this  will  be 
noted  by  a failure  to  update  the  interface.  If  the 
interface  between  avionics  and  one  channel  fails,  this 
will  be  detected  by  finding  a disagreement  in  mode  data 
exchanged  between  the  flight  control  channels.  Logic  is 
incorporated  to  insure  that  all  flight  control  channels 
engage  in  the  same  mode  if  this  happens . 


In  an  operational  system,  the  buffer  memory  could 
be  included  on  an  interface  module  card  in  the  remote 
terminal  (for  example,  on  the  input  interface)  thus 
eliminating  this  as  a 
separate  box  (although 
retaining  the  buffer 


function) . 

DEDICATED  PILOT  CON- 


TROL/DISPLAY 


In  order  to  give 
the  pilot  access  to 
flight  control  failure 
information  regardless 
of  the  status  of  the 
avionics  system,  a 
dedicated  panel  has 
been  incorporated  into 
other  dedicated  pilot 
instruments  as  shown 
in  Figure  7.  This 
panel  does  not  identi- 
fy which  specific  unit 
failed  to  che  pilot, 
but  only  whether  he 
has  zero,  one,  or  two 


failures  in  a given  axis,  and  what  type  of  unit  failed. 
Reset  is  attempted  by  pushing  buttons  labeled  pitch, 
roll,  and  yaw  (not  shown),  but  only  one  channel  can  be 
reset  at  a time.  Reset  simply  clears  the  mistrack 
counter  in  the  voter/monitor.  If  the  channel  has  a 
real  failure,  the  mistrack  counter  will  immediately 
exceed  the  limit  and  trip  out  again.  If  a channel  has 
a nuisance  trip  out  (i.e.,  due  to  a temporary  transient), 
it  will  not  refail  immediately.  Nuisance  trips  are 
possible  during  violent  maneuvers  and  it  appears  to  be 
impossible  to  eliminate  them  with  100%  confidence. 

The  reason  only  one  unit  may  be  reset  at  a time  is 
that  it  has  not  been  possible  to  devise  an  algorithm 
which  will  correctly  perform  failure  detection  when  two 
channels  are  good  and  two  have  identical  failures. 

Hence,  on  second  failure  only  one  channel  can  be  reset 
at  a time  so  that,  if  bad,  it  can  be  isolated  without 
question. 

The  failure  of  the  dedicated  control/display  panel 
causes  the  pilot  to  lose  display  of  failure  status  and 
ability  to  reset.-  The  failure  status  may  still  be 
displayed  in  the  multi-purpose  displays  in  the  cockpit 
if  the  avionics  system  is  operating. 
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A REDUNDANT  MULTIPLEX  DATA  BUS 
FOR  THE  F-18 


By  William  S.  Hermann  and  Kent  C.  Smith 
McDonnell  Aircraft  Company,  St.  Louis,  MO 


ABSTRACT 

This  paper  describes  the  avionics  multiplex  data  bus  system  being 
developed  by  McDonnell  Aircraft  Company  for  the  U.  S.  Navy  F-18  fighter/ 
attack  aircraft.  First,  a brief  comparison  of  first  and  second  genera- 
ls tion  multiplex  technology  illustrates  the  similarities  and  differences 

I in  F-18  and  F-15  data  bus  features.  Later  illustrations  describe  the 

basic  F-18  data  bus  characteristics  including  baseband  signalling  code, 
timing  and  synchronization,  line  coupling  and  bus  controller  concept. 

Also  included  are  descriptions  of  the  basic  data  bus  architecture,  as 
well  as  a bus/controller  block  diagram  with  controller  normal-mode  logic 
and  failure-mode  logic.  The  report  is  concluded  with  a discussion  of 
necessary  circuit  and  hardware  requirements  based  on  previous  design 
experience  and  a detailed  comparison  of  the  F-18  Mux  bus  specification 
with  MI L-STD-1 553  in  terms  of  quantitative  limits  of  terminal  input 
impedance  and  signal  voltage  as  well  as  driver  output  impedance,  voltage 
and  waveform  distortion. 

INTRODUCTION 

— 

The  F-18  aircraft  is  being  developed  by  McDonnell  Aircraft  for  the 
U.S.  Navy  and  Marine  Corps  in  cooperation  with  the  Northrop  Corporation. 

The  fighter  has  been  configured  for  optimum  performance  in  the  medium 
range,  beyond-visual  attack  as  well  as  the  visual  short  range,  high-g 
combat.  The  avionics  will  utilize  digital  technology  to  the  maximum 
extent  possible  with  major  emphasis  on  demonstrated  reliability.  A key 
element  in  the  avionics  reliability  is  the  capability  to  reliably  trans- 
fer digital  data  between  sensor,  processors  and  displays  located  through- 
out the  aircraft.  This  transfer  of  digital  data  to  the  mission  computers 
can  be  most  logically  and  efficiently  accomplished  by  multiplexing  (i.e., 
interleaving)  data  from  each  of  the  major  avionic  subsystems  into  a con- 
tinuous bit  stream  and  transmitted  over  a common  bus. 

This  paper  will  describe  the  F-18  approach  to  efficient  data  transfer 
using  a redundant  multiplex  bus  to  overcome  single-point  failures  inherent 
in  a single  transmission  path.  Also  a very  important  aspect  of  the  new 
architecture  is  the  ability  to  provide  a standard  interface  to  permit 
interchangeability  or  addition  of  new  avionics.  For  example,  the  addition 
of  new  avionics  equipment  in  current  generation  aircraft  requires  adapters, 
converters  or  in  extreme  cases,  design  modification  to  provide  a compatible 
interface.  In  contrast,  the  use  of  a compatible  standard  digital  interface, 
i.e.  MIL-STD-1553,  in  conjunction  with  additional  constraints  where  deemed 
advisable,  will  provide  for  growth  with  minimum  integration  .costs . This 
paper  will  address  the  compatibility  of  the  F-18  multiplex  system  with 
1553  as  well  as  identify  areas  where  additional  interface  contraints  are 
imposed. 
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A third  consideration  to  be  described  briefly  is  the  lessons 
learned  from  current  designs  and  recommendations  for  future  design. 


f 


One  final  word  of  qualification,  the  F-18  received  contract  go- 
ahead  on  22  January  1976,  with  the  first  flight  scheduled  for  August 
1978.  Since  we  are  now  only  nine  months  into  this  development  program, 
the  detailed  design  has  not  been  finalized.  We  intend  to  improve  and 
refine  this  design  configuration  during  the  remaining  24-month  period. 
Consequently,  the  information  to  be  presented  is  preliminary  in  nature. 

[ EVOLUTION  OF  AIRCRAFT  MULTIPLEX  TECHNOLOGY 

[ The  F-15  and  F-18  multiplex  systems  represent  almost  a decade  of 

technological  evolution  in  aircraft  systems  for  distribution  of  digital 
data.  Consequently,  they  represent  an  interesting  comparison  of  basic 
features.  Most  significant  is  the  use  of  synchronous  decoding  and 
timing  in  the  F-15  versus  asychronous  decoding  and  timing  in  the  F-18. 

In  the  asynchronous  system,  timing  is  derived  from  transitions  in  the 
incoming  bit  stream.  This  avoids  the  problem  of  time  skew  between  clock 
and  data  encountered  in  synchronous  decoders.  As  a consequence,  the 
asynchronous  system  can  tolerate  longer  bus  lines  in  the  order  of  300 
feet  compared  to  100  feet  in  the  synchronous  system.  These  limits  can 
be  reduced  or  extended  depending  to  some  extend  on  the  numbers  and 
length  of  stubs  on  the  line.  This  flexibility  is  becoming  a signifi- 
cant factor  in  future  fighter/attack  aircraft  since  growth  and  addi- 
tional requirements  can  far  exceed  the  original  expectations  for  bus 
length.  Also  the  advanced  avionics  configurations  involve  more  equip- 
ment and  greater  interchange  of  data. 


EVOLUTION  OF  MULTIPLEX  TECHNOLOGY 


F-15 

F-18 

SYNCHRONOUS 

ASYNCHRONOUS 

CENTRAL  CLOCK  TIMING 
CLOCK  GATED  DETECTOR 

DATA  STREAM  TIME  REFERENCE 
DIFFERENTIAL  DETECTOR 

WORD  GAP  SYNC 

INVALID  SYNC  CODE 

MONITORED  REDUNDANT  BUS 

MONITORED  REDUNDANT  BUS 

CENTRAL  CONTROLLER/PROCESSOR 

DUAL  CONTROLLER/PROCESSOR 

Word  and  message  synchronization  in  the  two  systems  also  provides 
a distinctive  comparison.  The  use  of  a gap  or  off  time  provides  a 
simple  method  in  the  F-15  where  word  and  message  separation  is  fixed 
at  five  bits  and  eight  bits,  respectively,  and  where  central  clock 
timing  provides  a reference  gate  for  the  decoder.  In  contrast,  the 


invalid  sync  code  at  the  start' of  each  word  in  the  F-18  message  format 
permits  the  use  of  differential  or  asynchronous  decoding  independent 
from  any  central  time  reference.  Also,  the  redundancy  employed  in 
normal  and  failure  modes  of  the  two  systems  are  distinctly  different 
with  regard  to  number  of  back-up  bus  lines  and  back-up  processing  capa- 
bility. This  will  be  described  in  a subsequent  illustration.  The 
number  of  data  bits  is  16  plus  parity  in  both  cases;  however,  the  word 
length  is  different  due  to  the  three  bit  long  sync  code  used  for  the 
F-18  format. 

1553/F-18  MUX  BUS  CHARACTERISTICS 


The  F-18  avionics  multiplex  system  follows  the  design  configuration 
and  bus  characteristics  set  forth  in  MI L-STD-1 553.  Transformer  coupling 
to  a Twisted  Shielded  Pair  is  used  with  balanced  line  drivers  and 
receivers  to  provide  substantial  reduction  in  common-mode  noise  compared 
to  an  unbalanced  line.  It  also  prevents  coupling  of  DC  ground  loops  and 
circulating  currents  into  the  balanced  line.  A Bi 0 level  or  Manchester  II 
code  permits  self-clocking  and  AC  coupling  due  to  the  occurrence  of 
a transition  in  each  bit.  The  Bi0  signal  also  permits  asynchronous 
detection  of  the  incoming  data  stream  without  need  for  separate  clock 
lines.  The  differential  timing  provided  by  a bit-to-bit  asynchronous 
time  reference  permits  the  use  of  a relatively  long  bus.  The  invalid 
sync  code  provides  capability  to  detect  a sync  bit  duration  of  a one 
and  one-half  bit  pulse  as  contrasted  to  detection  of  zero  crossings 
which  may  be  confused  with  low  energy  noise  spikes.  Also,  the  invalid 
waveform  can  have  a positive  one  and  one-half  bits  followed  by  a neg- 
ative one  and  one-half  bits  or  a negative  followed  by  a positive  to 
identify  command  and  status  versus  data  words.  The  MHZ  baseband 
clocking  of  data  represents  a relatively  high  information  transfer 
rate  compatible  with  low  cost  integrated  circuit  logic.  The  command 
response  form  of  central  control  is  most  compatible  with  central 
executive  control  where  data  input/output  is  software  controlled  and 
specific  data  must  be  selectively  retrieved  for  real  time  computation 
of  air-to-air  fire  control  functions  or  air-to-ground  bomb  impact 
point.  The  use  of  a standard  interface  between  the  mission  processors 
and  avionic  subsystems  has  the  obvious  advantages  of  avoiding  special 
interface  boxes,  permitting  growth  to  economically  accommodate  new 
developments,  and  simplifying  interface  specification  and  management. 

1 553/F-1 8 MUX  BUS 
CHARACTERISTICS 


• TIME  DIVISION  DIGITAL  DATA 

• COMMAND  RESPONSE 
CENTRAL  CONTROLLER 

• 1 MHz  BASEBAND 

• STANDARD  INTERFACE 
FOR  INTERCHANGEABILITY 


• TRANSFORMER  COUPLED 

• BALANCED  LINE  TSP 

• Bi<J>  LEVEL  CODE 

• ASYNCHRONOUS 

• INVALID  SYNC  CODE 
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invalid  sync  code  at  the  start’ of  each  word  in  the  F-18  message  format 
permits  the  use  of  differential  or  asynchronous  decoding  independent 
from  any  central  time  reference.  Also,  the  redundancy  employed  in 
normal  and  failure  modes  of  the  two  systems  are  distinctly  different 
with  regard  to  number  of  back-up  bus  lines  and  back-up  processing  capa- 
bility. This  will  be  described  in  a subsequent  illustration.  The 
number  of  data  bits  is  16  plus  parity  in  both  cases;  however,  the  word 
length  is  different  due  to  the  three  bit  long  sync  code  used  for  the 
F-18  format. 

1 553/F-18  MUX  BUS  CHARACTERISTICS 


The  F-18  avionics  multiplex  system  follows  the  design  configuration 
and  bus  characteristics  set  forth  in  MI L-STD-1 553 . Transformer  coupling 
to  a Twisted  Shielded  Pair  is  used  with  balanced  line  drivers  and 
receivers  to  provide  substantial  reduction  in  common-mode  noise  compared 
to  an  unbalanced  line.  It  also  prevents  coupling  of  DC  ground  loops  and 
circulating  currents  into  the  balanced  line.  A Bi 0 level  or  Manchester  II 
code  permits  self-clocking  and  AC  coupling  due  to  the  occurrence  of 
a transition  in  each  bit.  The  Bi 0 signal  also  permits  asynchronous 
detection  of  the  incoming  data  stream  without  need  for  separate  clock 
lines.  The  differential  timing  provided  by  a bit-to-bit  asynchronous 
time  reference  permits  the  use  of  a relatively  long  bus.  The  invalid 
sync  code  provides  capability  to  detect  a sync  bit  duration  of  a one 
and  one-half  bit  pulse  as  contrasted  to  detection  of  zero  crossings 
which  may  be  confused  with  low  energy  noise  spikes.  Also,  the  invalid 
waveform  can  have  a positive  one  and  one-half  bits  followed  by  a neg- 
ative one  and  one-half  bits  or  a negative  followed  by  a positive  to 
identify  command  and  status  versus  data  words.  The  MHZ  baseband 
clocking  of  data  represents  a relatively  high  information  transfer 
rate  compatible  with  low  cost  integrated  circuit  logic.  The  command 
response  form  of  central  control  is  most  compatible  with  central 
executive  control  where  data  input/output  is  software  controlled  and 
specific  data  must  be  selectively  retrieved  for  real  time  computation 
of  air-to-air  fire  control  functions  or  air-to-ground  bomb  impact 
point.  The  use  of  a standard  interface  between  the  mission  processors 
and  avionic  subsystems  has  the  obvious  advantages  of  avoiding  special 
interface  boxes,  permitting  growth  tc  economically  accommodate  new 
developments,  and  simplifying  interface  specification  and  management. 

1 553/F-1 8 MUX  BUS 
CHARACTERISTICS 


• TIME  DIVISION  DIGITAL  DATA 

• COMMAND-RESPONSE 
CENTRAL  CONTROLLER 

• 1 MHz  BASEBAND 

• STANDARD  INTERFACE 
FOR  INTERCHANGEABILITY 


• TRANSFORMER  COUPLED 

• BALANCED  LINE-TSP 

• Bi<t>  LEVEL  CODE 

• ASYNCHRONOUS 

• INVALID  SYNC  CODE 
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UNIQUE  FEATURES  OF  THE  F-18  MUX  BUS 


In  addition  to  meeting  all  the  requirements  of  the  MIL-STD-1553 
document  with  the  F-18  multiplex  bus  experience  leads  us  to  believe 
that  additional  constraints  can  provide  an  increase  in  performance 
margin  while  retaining  the  desired  interface  compatibility.  For  example, 
in  certain  designs  the  Biphase  output  waveform  from  the  line  driver  is 
essentially  a square  wave  containing  significant  levels  of  third  and 
fifth  harmonics  as  well  as  lesser  levels  of  higher  harmonics.  Since 
these  harmonics  do  not  enhance  the  signal  detection  probability  and 
do  produce  unwanted  radio  frequency  interference,  we  have  elected  to 
filter  the  line  driver  output  prior  to  coupling  to  the  bus. 


UNIQUE  FEATURES  OF  THE 
F-18  MUX  BUS 


• BANDWIDTH  LIMITING  (Bi<t>  FILTERING) 

• SURVIVABILITY  WITH  DUAL  CONTROLLERS 

• REDUNDANT  BUS  CONFIGURATION 

• RT  RESPONSE  WITH  STATUS  WORD  ON  MODE  COMMAND 


• THRESHOLD  LEVEL  FOR  NOISE  REJECTION 

— 700  MV  P-P,  L L 


The  F-18  uses  two  mission  computers  and  associated  bus  controllers 
in  the  normal  mode  that  communicate  with  a number  of  distributed  sub- 
system computers/processors  in  a hierarchal  system  architecture. 

Mission  related  functions  such  as  navigation,  flight  control,  com- 
munications, fire  control,  weapon  delivery,  display  data  base  manage- 
ment and  stores  management  are  assigned  to  a specific  mission  computer. 
Back-up  programs  in  each  computer  provide  a significant  fail  operational 
capability.  Each  data  channel  uses  a redundant  bus  pair  for  additional 
dependability.  Each  bus  is  monitored  by  all  remote  terminals  on  the 
data  channel.  Other  features  include  the  F-18  use  of  the  mode  command 
transfer  option  described  in  MIL-STD-1553  to  command  remote  terminal 
mode  changes.  For  example, -a  mode  command  to  the  autopilot  can  result 
in  a change  to  the  outer  loop  mode  and  an  autopilot  response  with  a status 
word  indicating  message  acknowledge.  A last,  but  nevertheless  impor- 
tant feature,  is  the  use  of  a 700  millivolt  threshold  gate  to  exclude 


I4r 


all  noise  and  indetectable  signals  below  the  threshold.  As  a result, 
the  signal  to  noise  power  per  bit  (E/No)  is  increased  with  only  a 
nominal  reduction  in  signal  level  to  the  detector  and  a very  small 
change  in  probability  of  bit  detection  error. 

F-18  AVIONICS  MULTIPLEX  DATA  BUS  ARCHITECTURE 


The  F-18  bus  architecture  has  been  briefly  described  as  two  inde- 
pendent mission  programmed  processors  which  interface  with  two  independent 
data  channels.  Remote  terminal  or  subsystems  transmit  and  receive  data 
on  an  assigned  data  channel  which  is  common  to  both  processors.  This 
permits  each  processor  to  command  data,  mode  change  or  status  from  remote 
terminals  on  either  data  channel. 


F-18  AVIONICS  MULTIPLEX 
DATA  BUS  ARCHITECTURE 


DATA  CHANNEL  “A" 


Note:  Typical  for  one  of  two  data  channels. 
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F-18  AVIONICS  MULTIPLEX  DATA  BUS  AND  SUBSYSTEM  INTERFACE 


The  two  mission  computers  interface  with  each  of  the  avionics 
subsystems  using  a redundant  bus  pair  for  each  data  channel.  It  is 
important  to  note  that  the  remote  terminals  are  physically  contained 
within  each  subsystem.  This  integrated  system  approach  avoids  the 
proliferation  of  additional  boxes  that  would  be  required  if  the 
terminals  were  physically  separated  from  the  subsystems  and  packaged 
as  a line  replaceable  unit.  Consequently  the  additional  costs  of 
qualification,  installation,  cabling,  spares,  logistics,  handbooks, 
AGE  and  training  for  the  additional  LRU's  are  avoided.  In  addition, 
the  integrated  approach  simplifies  the  system  specification  and 
management  of  interfaces  and  permits  clear  definition  of  responsi- 
bility for  subsystem  performance. 
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F-18  AVIONICS  MULTIPLEX  DATA  BUS 

The  avionics  multiplex  data  transfer  between  the  two  mission  com- 
puters is  shown  in  the  functional  diagram.  Each  computer  has  three  I/O 
channels.  Each  remote  terminal  transmits,  receives  and  processes  data 
on  bus  "X"  while  simultaneously  monitoring  bus  "Y"  for  commands  from 
either  mission  computer.  In  the  event  a valid  status  is  not  received 
by  a controller  in  response  to  a command  word,  the  controller  will 

F-18  AVIONICS  MULTIPLEX  DATA  BUS 

I 1 1 BUS  "X"  | 1 


RCV/XMT 


— I — DATA  _L  1 1_ 

RT  CHANNEL  RT  RT  RT 

"a"  Ln— 1 L-rJ  r~ 


BUS "Y" 


XMT/RCV 


shift  to  multiplex  bus  "Y1  and  repeat  the  command.  Although  this  back- 
up access  to  data  from  remote  terminals  meets  stringent  fail  operational 
requirements,  two  additional  methods  of  data  access  are  inherent  to 
the  bus/controller  architecture.  First,  data  channel  "C"  is  available 
for  transfer  of  data  buse  information  from  one  computer  to  the  other. 
Since  dynamic  data  from  remote  terminals  is  updated  at  20  times  per 
second,  the  transferred  data  is  compatible  with  mission  dynamic  require- 
ments. A second  potential  data  access  method  would  require  additional 
software  to  permit  the  seond  computer  to  request  data  from  a terminal 
and  relay  it  to  the  first  computer.  Due  to  the  survivability  of  the 
dual  processors  and  redundant  MUX  bus,  this  access  method  will  be 
reserved  for  growth  or  future  priority  requirements. 

CONTROLLER  TO  CONTROLLER  PRIORITY  LOGIC 


Since  both  controllers  have  access  to  each  data  channel,  it  is 
necessary  to  establish  control  logic  and  priority  for  channel  usage. 

In  the  initial  or  start-up  condition,  each  controller  is  programmed 
to  transmit  on  an  assigned  bus  as- illustrated  in  the  previous  block 
diagram.  In  other  words,  mission  computer  "one"  will  transmit  on  data 
channel  "B"  and  mission  computer  "two"  will  transmit  on  data  channel 
"A".  Channel  control  is  transferred  between  computers  using  the 
dynamic  bus  allocation  mode  command.  When  a given  controller  has 
completed  all  its  required  transfe-s,  it  will  send  the  dynamic  bus 
allocation  mode  command  to  the  other  controller.  Receipt  of  the  mode 
command  is  acknowledged  and  the  second  controller  takes  command  of  the 
channel.  When»  seffsnd  controller  has  completed  its  use  Of  the  bus, 
it  returns  bus  control  to  the  first  controller.  Each  controller  moni- 
tors the  bus  priority  to  ensure  that  each  channel  is  properly  managed; 
if  channel  control  is  not  transferred  properly,  the  offending  controller 
can  be  shut  down  and  the  remaining  controller  takes  over  in  a back-UD 
mode.  In  addition,  a "watchdog"  timer  is  used  in  accordance  with  the 
660  microsecond  transmission  t‘me-out  specified  by  1553  to  detect  that 

COMTROLLER  TO  CONTROLLER 
PRIORITY  LOGIC 

• EACH  CONTROLLER  PROGRAMMED  TO  START  TRANSMITTING 
ON  ASSIGNED  BUS 

• EACH  CONTROLLER  WILL  TEST  VALIDITY  OF  THE  ASSIGNED 
BUS  ONLY 

• EACH  CONTROLLER  WILL  SEND  A DYNAMIC  BUS  ALLOCATION 
WORD  TO  SIGNIFY  MESSAGE  COMPLETE  AND  PERMIT  OTHER 
CONTROLLER  TO  TAKE  COMMAND 

• ORIGINAL  CONTROLLER  WILL  REGAIN  CONTROL  WHEN  A 
DYNAMIC  ALLOCATION  WORD  IS  RECEIVED 

• BUS  UTILIZATION  TIME  BY  EACH  CONTROLLER  IS  CAREFULLY 
PLANNED  TO  BA'  ANCE  BUS  LOADING 

• CONTROLLER  HAS  OPTION  TO  OBTAIN  DATA  FROM  OTHER 
CONTROLLER  BY  DATA  BASE  TRANSFER 
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the  operational  program  has  stopped  or  is  abnormally  delayed.  A further 
requirement  which  is  critical  in  the  operation  of  two  independent  con- 
trollers is  the  careful  design  of  softv/are  to  insure  that  the  bus 
utilization  time  by  each  controller  does  not  exceed  the  total  capability. 

Bus  utilization  by  each  controller  is  carefully  allocated  and  the 
1553  data  rate  potential  ensures  sufficient  remaining  capacity  not 
just  for  the  current  F-18  application  but  for  future  growth  as  well. 
First,  the  processing  of  data  in  the  hierarchal  system  architecture 
is  distributed  by  providing  appropriate  sensor  computations  in  the 
various  sensors,  with  the  mission  computers  dedicated  to  mission- 
oriented  computations  requiring  data  from  several  sources.  Secondly, 
messages  from  the  RTs  to  the  controllers  are  partitioned  to 
minimize  the  required  control ler-to-controller  data  transfers.  The 
priority  and  control  logic  of  the  channel  management  by  the  controllers 
is  under  software  control  and  is,  therefore,  capable  of  modification 
to  meet  the  changing  needs  of  this  evolving  system. 

CONTROLLER  TO  RT  PRIORITY  LOGIC 

In  addition  to  defining  priority  for  two  bus  controllers  and  pro- 
cessors, it  is  also  necessary  to  define  priority  of  operation  of 
redundant  multiplex  buses.  As  previously  illustrated  in  the  data  bus 
block  diagram,  one  group  of  remote  terminals  report  on  data  channel 
"A"  and  a second  group  on  data  channel  "B".  Each  channel  consists  of 
two  buses:  i.e.,  bus  "X"  and  bus  "Y".  The  terminals  normally  report 

on  one  bus  "X"  and  monitor  the  other  bus  for  command  words.  If  a command 
word  is  detected  on  bus  "Y",  (indicating  invalid  status,  failure  to 
respond  to  controller  command,  or  a higher  priority  processing  require- 
ment) the  remote  unit  immediately  terminates  message  processing  with 
bus  "X"  and  begins  command  word  monitoring  of  that  bus.  The  remote 
will  continue  to  validate  the  remainder  of  the  command  word  on  bus  "Y" 
and  process  the  message.  The  controller  option  to  remain  on  bus  "Y"  or 
shift  to  bus  "X"  for  subsequent  operation  will  depend  on  software 
implementation  although  it  is  probable  that  bus  "Y"  would  continue  to 
be  used. 

CONTROLLER  TO  RT 
PRIORITY  LOGIC 

• EACH  RT  INTERFACES  WITH  TWO  BUSES 

• RT  RECEIVER  DETECTS  CONTROLLER  COMMAND 

• TERMINATE  MESSAGE  PROCESSING  WITH  SECOND  BUS 

• RETURN  TO  COMMAND  WORD  MONITOR  OF  NO.  2 BUS 

• CONTINUE  TO  VALIDATE  REMAINDER  OF  COMMAND 
WORD  AND  PROCESS  SECOND  MESSAGE 
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COMPARISON  OF  TERMINAL  INPUT-OUTPUT  LIMITS 

This  table  compares  the  limit  values  of  the  MI L-STD-1 553  specification 
with  the  MDC-3818  which  have  been  converted  from  peak-to-peak  as  they  appear 
in  the  specification  to  zero-to-peak  for  direct  comparison  with  1553. 

Also,  the  open  circuit  driver  output  voltage  specified  in  3818  has  been 
converted  to  include  the  attenuation  of  the  isolation  resistors  as 
well  as  zero-to-peak  values.  Nevertheless,  the  driver  output  limits 
appear  to' be  more  restrictive  but  within  the  three  to  ten  volt  limits 
of  1553.  This  difference  is  due  to  the  method  of  defining  the  load 
termination.  1553  specifies  a 300  foot  cable  and  not  less  than  33  other 
remote  terminals  attached  by  means  of  cable  stubs  not  to  exceed  twenty 
feet  in  length.  In  comparison,  3818  specifies  a cable,  up  to  300  feet 
in  length,  operating  under  any  normal  or  faulted  cable  condition  including 
opens,  direct  line-to-line  shorts  or  loss  of  all  termination  resistors. 


COMPARISON  OF  TERMINAL  INPUT-OUTPUT  LIMITS 


1553 

3818 

INPUT  IMPEDANCE  (NOT  XMT)  (MIN)  

2000  V. 

2200  n 

INPUT  SIGNAL  RESPONSE  VOLTAGE 

MINIMUM 

0.5  V 

0.5  V* 

MAXIMUM 

10  V 

10  V* 

INPUT  SIGNAL,  NO  RESPONSE  THRESHOLD 

0.7  V 

DRIVER  OUTPUT  IMPEDANCE  (MAX) 

ion 

DRIVER  OUTPUT  VOLTAGE  (MIN-MAX)  (OPN  CKT).. 



28  36  V (P-P) 

12  dB  ATTENUATION  IN  ISOLATION  RES 

. 3 - 10 V 

3.5  - 4.5  V 

DRIVER  OUTPUT  HARMONIC  ATTENUATION 
1.5MHz 

> 3 dB 

2.5  MHz 

> 13.5  dB 

4.0  MHz 

> 25.5  dB 

OUTPUT  WAVEFORM  ZERO  CROSSING  DEVIATION 

25  ns 

15  ns 

OUTPUT  WAVEFORM  RISE/FALL  TIME 

(10-90%  POINTS) 

> 100  ns 

SINUSOIDAL 

OUTPUT  PEAK  AMPLITUDE  VARIATION  (FROM 
AVERAGE  PEAK) 

15% 

Note:  All  values  are  measured  line-to-line. 

All  values  are  measured  zero-to-peak,  except  as  noted. 
* Indicates  values  are  shown  as  peak-to-peak  in  specification. 


Variation  of  driver  output  voltage  with  remote  terminals  and  stubs  is 
not  specified  due  to  the  wide  range  of  amplifying  and  attenuating  effects 
which  can  occur  at  various  points  along  the  line.  From  this  comparison, 
it  is  apparent  that  the  3818  requirements  equal  or  exceed  those  in  the 
MI L-STD-1 553 . There  is  no  direct  comparison  of  input  signal  threshold, 
driver  output  impedance  or  waveform  filtering  since  these  requirements 
are  not  defined  by  1553. 
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COMPARISON  OF  WAVEFORM  DISTORTION  LIMITS 

As  previously  indicated,  one  of  the  unique  features  of  the  F-18 
avionics  multiplex  system  is  the  use  of  line  driver  filtering  to  reduce 
the  harmonic  level  of  the  transmitted  signal.  As  shown  in  the  illustra- 
tion, the  3818  spec  limits  the  driver  output  harmonics  to  13.5  dB  or 
greater  below  the  signal  at  2.5  MHz  and  25.5  dB  or  greater  at  4.0  MHz. 
Also  the  variation  in  peak  amplitude  of  the  waveform  is  limited  to  15 
percent  above  or  below  the  average  value  of  the  peak  signal.  The  only 
direct  comparison  between  1553  and  3818  in  terms  of  waveform  distortion 
is  the  maximum  value  of  zero-crossing  deviation  permitted.  The  3818 
spec  is  somewhat  more  restrictive  with  a limit  of  15  nanoseconds  com- 
pared to  25  nanoseconds  in  1553. 

In  summary,  the  F-18  avionics  multiplex  system  meets  or  exceeds 
the  requirements  of  MI L-STD-1 553 . Constraints  such  as  filtering 
and  thresholding  increase  the  performance  margin  while  retaining  the 
desired  interface  compatibiltity. 


MULTIPLEX  DATA  BUS  CONFERENCE 


3-5  November  1976 
Dayton,  Ohio 


SESSION  III 

"NEW  DATA  BUS  CONCEPTS" 


MODERATOR: 

ROBERT  B.  KLEINMAN,  Col,  USAF 
Assistant  Deputy 

Deputy  for  Aeronautical  Equipment 
Aeronautical  Systems  Division 
Wright-Patterson  AFB,  Ohio 


147 


NAVAL  ELECTRONIC  LABORATORY  CENTER  ACTIVITIES  IN  DATA  BUS, 
FIBRE  OPTIC  AND  HIGH  SPEED  DIGITAL  SWITCHING 

by 

Dieter  H.  Marcus 

Naval  Electronic  Laboratory  Center 
(NELC/3540) 

271  Catalina  Blvd. 

San  Diego,  California  92152 


This  paper  did  not  reach  us  in  time  to  be 
included  in  the  Proceedings . Please  contact 
the  author  for  a copy  of  this  paper. 

With  permission  of  the  Navy,  a SDMS  brochure 
has  been  reproduced  here,  in  part.  It  covers 
some  of  the  material  that  was  intended  to  be 
presented  at  the  conference. 
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WHY  IS  SDMS  MULTIPLEXING  UNIQUE? 
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HOW  DOES  SDMS  WORK? 


HEADER  WORD  #1  WORD  #2  < < WORD  #N 


SUCCESSIVE  UPDATES  WILL  TAKE  RANDOM  PATHS 


Each  half  of  an  AM  is  tied  via  separate  isolated  stubs  to  all  the  installed 
primary  multiplex  cables.  Each  cable  provides  four  FDM  data  channels.  A 
five-cable  installation  therefore  provides  20  AM-to-AM  data  paths.  Each 
message  update  occurs  on  a random  data  channel  of  a randomly  selected 
cable. 


Dual-redundant  remote  multiplexer  shared-electronics  (RMSE) 
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HOW  DOES  A MESSAGE  KNOW  WHAT  CABLE  TO  USE? 
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ABSTRACT 

An  eight-station  EMI/EMP  resistant  avionic  data  bus  has 
been  constructed  and  tested  which  uses  the  protocol  and  organ- 


ization set  forth  in  MIL-STD-1553 ( USAF) . The  bus  uses  a data 
rate  of  lOMbit/s  with  fiber  optic  bundles  as  the  data  trans- 
mission medium.  The  system  also  employs  GaAs  Light  Emitting 
Diodes  (LEDs),  silicon  PIN  photodiodes,  and  passive  optical 


couplers.  The  passive  optical  coupler  makes  it  possible  for 
each  station  to  receive  optical  signals  from  the  bus  and 
transmit  optical  signals  onto  the  bus  without  the  use  of 
repeaters.  Damage  to  a station  affects  only  that  station 
without  impairing  the  operation  of  the  remainder  of  the  bus. 

An  overall  system  description  and  design  approach  is  presented 
with  emphasis  on  the  characteristics  of  the  critical  opto- 
electronic interfaces.  The  system  uses  eight  Multiplex  Terminal 
Units  (MTUs)  inter-connected  with  a nine  port  radial  coupler. 
Pluggable  optical  interfaces  are  employed  with  fiber  optic 
cable  lengths  of  10ft,  20ft,  30ft,  and  50ft.  This  gives 
optical  path  lengths  of  20ft  minimum  and  100ft  maximum.  The 
maximum  allowable  optical  attenuation  is  45dB.  Unipolar 
Manchester  coding  is  used  on  the  optical  bus  with  a data  rate 
of  lOMbit/s  and  a worst  case  bit  error  rate  of  1x10“ 8 . 


tThis  work  was  supported  by  the  Air  Force  Avionics  Laboratory, 
Wright  Patterson  AFB , Ohio  45433  on  Contract  F33615-74-C-1001 
Project  2003-07-04. 
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INTRODUCTION 


The  design  concept  for  advanced  avionic  systems  now  under 
development  is  moving  toward  the  utilization  of  centralized 
data  management  techniques  which  emphasize  automatic  operation, 
maximum  use  of  sensors,  mission  flexibility,  growth  capabili- 
ties and  fault  tolerance.  This  change  in  design  concept  places 
stringent  requirements  on  the  data  distribution  system  which 
can  not  be  met  by  the  dedicated  hard  wire  approach  used  in  the 
past. 


Optoelectronic  data  transmission,  based  on  the  use  of 
light  emitting  diodes  (LEDs) , multimode  flexible  fiber  optic 
bundles  and  silicon  photodiodes,  offers  an  information  trans- 
mission capability  that  is  consistent  with  military  require- 
ments and  potentially  superior  to  wire  techniques.  The  opto- 
electronic interface  is  ideally  suited  for  use  in  high  data 
rate  digital  data  buses.  Thus,  this  emerging  technology  offers 
a viable  means  of  responding  to  the  increasing  bandwidth  re- 
quirements of  new  avionics  systems.  At  the  same  time,  the 
optoelectronic  interface  offers  the  unique  features  of 

o isolation  from  ground  plane  signals  from  dc  to  RF, 

o light  weight 

o dramatically  improved  EMI/EMP  characteristics,  and 
o elimination  of  cross-talk. 

The  performance  of  present  optoelectronic  components  makes 
it  possible  to  operate  digital  optoelectronic  systems  at  data 
rates  in  excess  of  lOOMbit/s  Manchester. 

GENERAL  DESCRIPTION 

The  fiber  optic  data  bus  system  described  in  this  paper 
is  a time  division  multiplex  system  capable  of  handling  actual 
data  transmission  between  remote  terminals  at  a data  rate  of 
lOMbit/s.  The  bus  configuration,  shown  in  the  block  diagram 
of  Figure  1,  is  basically  as  described  in  MIL-STD-1553 ( QSAF) 1 . 
The  items  of  equipment  which  comprise  the  system  are  listed 
in  Table  1 and  shown  in  the  photograph  in  Figure  2.  There 
are  three  basic  differences  between  this  system  and  MIL-STD- 
1553  (AFAL).  These  differences  are: 

(1)  The  data  on  this  bus  is  lOMbit/s  optical  instead 
of  l.OMbit/s  electrical.  To  the  extent  practical. 


Table  1.  Equipment  Supplied 
Multiplex  Terminal  Unit  (MTU) 


7 each 


Control  Multiplex  Terminal  Unit  (CMTU)  1 each 


MTU  Test  Set  (SSIU) 

CMTU  Test  Set  (Controller) 

9 port  Radial  Coupler 

Fiber  Optics  Radial  Coupler  Cable 

Assembly 

Consisting  of: 

2 each  10ft  fiber  optic  cable 
2 each  20ft  fiber  optic  cable 
2 each  30ft  fiber  optic  cable 
2 each  50ft  fiber  optic  cable 

SSIU/MTU  interface  cable 

Control ler/CMTU  interface 


2 each 


1 each 


1 each 


1 each 


2 each 


1 each 


a complete  10:1  rate  scaling  was  done — preamble 
lengths,  interword  delays,  etc.  being  one  tenth  of 
the  value  specified  in  MIL-STD-1553 (USAF) . The  data 
interchange  between  the  MTU  and  the  Sub  System 
Interface  Units  (SSIUs)  is  parallel  at  1.0M  word/s 
as  specified  in  MIL-STD-1553 (UFAF) 

(2)  The  MTUs  and  CMTU  were  constructed  as  stand-alone 
units  for  laboratory  demonstration  rather  than  plug- 
in modules  as  specified  in  MIL-STD-1553 (USAF) . 

(3)  The  MTUs  and  CMTU  contain  the  AC-to-DC  power  supplies 
required  for  all  internal  functions.  MIL-STD-1553 
specifies  that  DC  power  for  an  MTU  is  to  be  supplied 
by  its  respective  SSIU. 

The  data  bus  functions  asynchronously  in  a command/ 
response  mode.  All  transactions  on  the  bus  are  half-duplex 
operations  implemented  by  the  bus  controller  through  the 
CMTU.  Information  is  transferred  on  the  bus  by  messages 
comprised  of  three  types  of  words: 


Figure  3:  Message  Formats 


1.  Command  words 


2.  Status  words 

3.  Data  words 

The  message  formats  for  the  three  possible  modes  of  bus 
operation  are  shown  in  Figure  3 . 

In  the  controller  to  remote  terminal  transfer  mode,  the 
controller  issues  a receive  command  to  the  remote  terminal, 
followed  by  the  data  words.  The  remote  terminal  then  responds 
to  the  controller  with  a status  word. 

In  the  remote  terminal  to  controller  transfer  mode,  the 
controller  issues  a transmit  command  word.  The  remote  terminal 
then  responds  with  a status  word  followed  by  the  data  words. 

In  the  remote  terminal  to  remote  terminal  transfer  mode, 
the  controller  issues  a receive  command  to  the  receiving  remote 
terminal  followed  by  a transmit  command  to  the  transmitting 
remote  terminal.  The  transmitting  remote  terminal  then  responds 
with  a status  word  followed  by  the  data  words.  To  conclude 
this  transaction  the  receiving  remote  terminal  responds  with 
a status  word. 

The  command,  status  and  data  words  are  each  twenty  bit 
times  in  length  including  sync  and  parity.  Figure  4 shows 
the  format  of  each  type  of  word. 

The  command  word  is  comprised  of  a three  bit  time  sync 
waveform,  five  MTU  address  bits,  one  transmit/receive  bit, 
five  SSIU  code  bits,  five  word  count  bits  and  a parity  bit. 

The  data  word  is  comprised  of  a three  bit  time  sync 
waveform,  a five  bit  MTU  address,  a parity  error  bit,  nine 
MTU  failure  code  bits,  SSIU  status  bit  and  a parity  bit. 

The  data  code  on  the  bus  is  an  Optical  Manchester.  In 
this  code,  a logical  "1"  is  a high  state  for  the  first  half 
bit  and  a low  state  for  the  second  half  bit,  a logical  "0" 
is  a low  state  for  the  first  half  bit  period  and  a high  state 
for  the  second  half  bit  period. 

There  are  two  sync  codes  for  the  three  types  of  message 
words. 


Positive  Sync 
Negative  Sync 


Bit  Times: 


The  positive  sync  shown  in  Figure  5 is  used  in  the 
command  and  status  words.  It  is  an  invalid  Manchester  code 
where  the  first  three  half  bits  are  in  the  high  state  and  the 
last  three  half  bits  are  in  the  low  state.  When  the  leading 
data  bit  in  a command  word  or  a status  word  is  a "0",  as  shown 


Figure  5 : Command  and  Status  Sync 

in  Figure  5,  the  signal  stays  in  the  low  state  for  two  full 
bit  times.  This  constitutes  the  longest  low  state  condition 
that  can  occur  during  a valid  word. 

The  negative  sync  shown  in  Figure  6 is  used  in  the  data 
words.  It  is  an  invalid  Manchester  code  where  the  first  three 
half  bits  are  in  the  low  state  and  the  last  three  bits  are  in 
the  high  state. 


SSI 


16  Bit  Lines 


Command  Transfer 


MTU  Data  Transfer 


SSIU  Data  Transfer 


SSIU  Status 


Clock 


Figure  7:  MTU/SSIU  Interface 


MTU  DATA  TRANSFER 


SSIU  DATA  TRANSFER 


. <«  c.« 


{ 
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Command  Transfer 


J 


MTU  Data  Transfer 


Command  Transfer 


J 


SSIU  Data  Transfer 


L_ 


J 1 I L_ 


Figure  8:  MTU/SSIU  Interface  Timing  Diagram 
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When  the  last  data  bit  in  the  preceeding  data  word  is  a "1" 
as  shown  in  Figure  6,  the  word  sync  also  produces  a low  state 
signal  with  a duration  of  two  bit  times.  When  the  leading 
bit  in  a data  word  is  a "1"  (Figure  6) , the  signal  is  in  the 
high  state  for  two  bit  times.  This  constitutes  the  longest 
high  state  signal  that  can  occur  in  a valid  word. 

The  Multiplex  Terminal  Unit  (MTU)  provides  the  interface 
function  between  the  optical  data  bus  and  the  Subsystem  Inter- 
face Unit  (SSIU) . The  MTU  responds  to  a bus  command  received 
from  the  CMTU.Data  transfer  from  the  CMTU  to  the  MTU  is  held 
on  a message  basis  until  the  last  data  word  is  properly  re- 
ceived by  the  MTU,  at  which  time  the  entire  block  of  data 
words  is  transmitted  to  the  SSIU.  The  MTU  responds  to  a valid 
transmit  or  receive  command  within  .5  to  1.5  microseconds 
after  receipt  of  the  last  bit  of  the  command  or  last  data  word. 

The  MTU  provides  the  following  functions  for  the  remote 
terminal : 


1.  Provides  a 4MHz  clock  to  the  SSIU 

2.  Checks  incoming  command  words  for 

a.  correct  bit  count 

b.  parity 

c.  correct  address 

d.  transmit/receive  command 

3.  Checks  incoming  data  words  for 

a.  correct  bit  count 

b.  parity 

c.  data  drop  outs 

The  MTU/SSIU  interface  consists  of  control,  clock,  and 
bit  lines  as  shown  in  Figure  7.  This  interface  is  controlled 
by  the  MTU  command  transfer  line.  Interface  timing  is  shown 
in  Figure  8. 

The  MTU  designed  to  perform  the  above  functions  is  shown 
in  the  block  diagram  of  Figure  9.  The  received  Manchester 
data  stream  is  monitored  by  the  sync  detector  to  detect  a 
positive  sync  preamble.  When  a positive  sync  is  detected  the 
following  17  data  bits  are  converted  from  the  serial  Manchester 
BI-4>  format  to  a parallel  NRZ  format.  This  parallel  command 
word  is  then  checked  for  parity  and  correct  address.  If 
parity  and  address  are  both  correct,  the  command  word  is 
stored  in  the  Command  Register  while  type  of  command  is  de- 
coded from  the  T/R  bit. 

When  the  MTU  receives  a "transmit"  command,  the  command 
word  is  transferred  through  the  channel  select  and  data 
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Figure  9 : Data  Bus  MTU  Block  Diagram 


transceiver  to  the  SSIU.  At  the  same  time  transmission  of 
the  MTU  status  word  is  begun,  the  SSIU,  upon  receipt  of  the 
transmit  command  word,  will  start  transferring  data  words  to 
the  MTU.  These  data  words  have  to  be  temporarily  stored  be- 
cause data  transfer  between  the  MTU/SSIU  is  at  twice  the  data 
rate  of  data  transfer  on  the  optical  bus.  When  a data  word 
is  to  be  transmitted  it  is  read  from  memory  and  transferred 
to  the  output  section  of  the  MTU  where  a parity  bit  is  added 
and  the  word  is  converted  from  a parallel  NRZ  format  to  a 
serial  Manchester  data  format  with  sync  addition  and  is  then 
transmitted. 

When  the  MTU  receives  a "receive"  command  word,  it  imme- 
diately looks  for  a negative  sync  format  and  data  word.  Each 
data  word  is  received  and  checked  for  parity  in  the  same  manner 
as  the  command  word.  It  is  then  stored  in  the  data  register 
where  it  will  then  be  read  into  memory.  After  the  last  data 
word  is  received  and  stored,  transmission  of  the  status  word 
is  begun.  If  all  of  the  data  words  have  been  received  with 
no  errors,  the  receive  command  is  then  transferred  through 
the  channel  select  and  Data  Transceiver  to  the  SSIU.  The 
channel  select  is  then  switched  to  the  memory  and  the  data 
words  are  transferred  to  the  SSIU. 

The  Control  Multiplex  Terminal  Unit  (CMTU)  provides  the 
interface  function  between  the  optical  bus  and  the  controller. 
The  operation  of  the  CMTU  is  similar  to  the  MTU  except  that 
the  CMTU  responds  to  commands  received  from  the  controller. 

The  CMTU  responds  to  three  different  commands  from  the  con- 
troller whereas  the  MTU  responds  to  only  two  commands.  The 
three  commands  control  the  three  modes  of  bus  operation. 

The  CMTU  provides  the  following  functions  for  the  control 
terminal: 

1.  Provides  4MHz  clock  to  controller 


2.  Checks  incoming  status  words  for: 

a.  correct  bit  count 

b.  parity 

c.  status  error  conditions 

3.  Checks  incoming  data  words  for: 

a.  correct  bit  count 

b.  data  dropouts 

c.  parity 


Command  Transfer 
Controller  Data  Transfer 


MTU  Data  Transfer 
Successfully  Complete 
Error  Condition 


4 MHZ  Clock 


The  CMTU/Controller  interface  consists  of  control,  clock, 
and  bit  lines  as  shown  in  Figure  10.  This  interface  is  con- 
trolled by  the  controller  through  the  command  transfer  line. 
The  interface  timing  is  shown  in  Figure  11. 

A simplified  block  diagram  of  the  CMTU  is  shown  in  Figure 
12.  The  CMTU  is  similar  to  the  MTU  in  operation  except  that 
the  control  commands  come  from  the  controller  instead  of  from 
the  data  bus.  The  CMTU  also  has  no  address  associated  with 
it.  The  CMTU  initiates  and  controls  all  bus  operation  with 
the  supervision  of  the  controller. 

The  controller  directs  the  CMTU  to  initiate  bus  operation 
by  the  transfer  of  one  of  three  types  of  commands: 

(1)  Transmit  data  from  controller  to  remote  terminal 

(2)  Transmit  data  from  remote  terminal  to  controller 

(3)  Transmit  data  from  remote  terminal  to  remote  terminal 

The  CMTU  transmits  the  appropriate  command  word,  via  the 
data  bus,  to  the  desired  remote  terminal.  The  CMTU  then 
monitors  the  data  bus  for  correct  operation  by  detecting  and 
receiving  status  words  from  the  remote  terminals.  These 
status  words  indicate  the  condition  of  the  bus  operation  with 
the  proper  code  for  correct  or  error  condition.  If  the  status 
word  indicates  an  error  condition,  the  status  word  is  trans- 
ferred to  the  controller  via  the  error  condition  transfer 
control.  If  the  status  word  indicates  no  error  condition, 
the  status  word  is  transferred  to  the  controller  via  the 
satisfactory  complete  transfer  control.  In  the  event  that 
no  status  word  is  received  after  a bus  command,  it  is  assumed 
that  an  error  condition  occurred  in  the  transmission  or  the 
reception  of  the  command  word.  When  this  condition  occurs 
no  transfer  is  made  between  the  CMTU  and  Controller. 

In  the  controller  to  remote  terminal  mode,  the  controller 
transfers  a "receive"  command  to  the  CMTU  followed  by  the 
data  words.  The  CMTU  receives  the  command  word  and  stores 
it  in  a command  register.  It  is  then  converted  from  a par- 
allel NRZ  format  to  a serial  Manchester  format  with  sync 
addition  and  transmitted.  The  data  words  are  then  read 
from  memory  and  transmitted  in  the  same  manner  as  the  command 
words.  The  CMTU  then  detects  a positive  sync  from  the  in- 
coming status  word.  The  status  word  is  converted  from 
Manchester  to  NRZ  and  converted  to  a parallel  word  and  stored 
in  the  status  register.  The  status  word  is  then  checked  and 
transferred  to  the  controller. 
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In  the  remote  terminal  to  controller  mode,  the  controller 
transfers  a "transmit"  command  to  the  CMTU.  The  CMTU  receives 
the  command  word  and  stores  it  in  the  command  register.  The 
CMTU  then  transmits  the  command  word  to  the  MTU.  The  CMTU 
then  receives  and  stores  the  status  word  from  the  MTU.  The 
status  word  is  followed  by  the  data  words  which  are  checked 
and  stored  in  the  buffer  memory.  After  the  last  data  word 
has  been  received  and  stored  the  status  word  is  transferred 
to  the  controller  followed  by  the  data  words. 

In  the  MTU  to  MTU  transfer  mode,  the  CMTU  receives  a 
receive  command  word  followed  by  a transmit  command  word. 

The  CMTU  starts  transmission  of  the  receive  command  word  to 
the  MTU  immediately  after  it  is  received.  After  the  trans- 
mission of  the  transmit  command  word  the  CMTU  receives  a 
status  word  from  the  transmit  MTU,  followed  by  the  data 
words.  The  status  word  is  checked  and  stored.  After  receiv- 
ing the  last  data  word,  the  CMTU  receives  a status  word  from 
the  receive  MTU.  This  status  word  is  checked  and  stored 
provided  the  first  status  word  contained  no  error  condition; 
the  CMTU  only  stores  one  status  word  at  a time.  The  stored 
status  word  is  then  transferred  t6  the  controller. 

The  MTUs  and  CMTUs  were  constructed  as  typical  bench- 
mounted  commercial  instruments.  All  have  tiltstands,  carry- 
ing handles  and  employ  forced  air  cooling. 

To  implement  construction,  the  MTUs  and  CMTU  were  broken 
down  into  7 separate  functional  subsystems.  This  provided 
for  ease  of  construction  as  each  section  could  be  built  on 
separate  PC  boards  and  checked  separately.  Also  the  simi- 
larity in  the  MTU  and  CMTU  function  would  allow  for  four  of 
the  MTU  subsystems  to  be  used  in  the  CMTU,  with  two  of  the 
remaining  three  requiring  minor  design  modification  to  imple- 
ment the  CMTU  function.  The  seven  subsystems  are: 

o Receiver  and  signal  conditioning 
o Transmitter 

o Sync  detection 

o Data  selection 

o Memory 

o Output 

o Timing  and  Control 

The  receiver,  signal  conditioning  and  transmitter  are 
constructed  on  separate  PC  boards  that  mount  to  the  back 
side  of  the  front  panel  of  either  the  MTU  or  CMTU.  Figure  13 
shows  the  preamp  and  LED  driver  boards  mounted  in  separate 
sections  of  a shielded  box.  The  LED  and  photodiode  are 
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separated  by  an  electrostatic  shield  in  the  front  panel 
connector  and  the  two  circuit  boards  are  shielded  behind  the 
panel.  This  type  construction  minimizes  coupling  between 
the  LED/driver  and  the  photodiode/preamp  within  the  station 
and  isolates  both  circuits  from  external  electromagnetic 
influences.  Wide-band  fiber  optic  receivers  can  be  con- 
structed which  have  very  low  input  noise.  Thus,  good  signal- 
to-noise  ratios  can  be  achieved  in  fiber  optic  data  trans- 
mission systems  at  signal  power  levels  far  below  those  nor- 
mally encountered  in  wire  systems.  The  receivers  built  for 
this  data  bus  system  give  a bit  error  rate  of  10“8  for  an 
optical  input  signal  of  167nW  (the  photodiode  current  is  83,3nA); 
the  receiver  bandwidth  is  10MHz.  Because  of  the  good  sensi- 
tivity of  fiber  optic  receivers,  it  is  important  that  ade- 
quate receiver  shielding  be  a part  of  every  fiber  optic  data 
transmission  system  design.  Otherwise,  much  of  the  EMI  and 
RFI  protection  afforded  by  the  fiber  optic  medium  can  be 
nullified  by  pickup  in  the  receiver.  Figure  14  shows  the 
signal  conditioning  circuit  board  mounted  outside  the  two 
shielded  compartments  containing  the  LED/driver  circuit  and 
the  photodiode/preamp  circuit.  When  the  cover  is  added  as 
shown  in  Figure  15,  a third  shielded  compartment  is  formed 
for  the  signal  conditioning  circuit.  The  signal  conditioning 
board  contains  principally  high  level  signals  that  are  not 
particularly  susceptible  to  pickup.  However,  this  board 
does  contain  a high-gain  postamp  which  raises  the  preamp  out- 
put to  the  level  of  about  1,0V,  The  preamp  and  postamp  have  a 
combined  transresistance  (voltage  out/current  in)  of  about 
2.4M2out  to  frequencies  of  the  order  of  10MHz.  It  is  impor- 
tant to  place  the  preamp  and  postamp  in  separate  compartments 
to  eliminate  capacitive  feedback  from  the  output  of  the  post- 
amp to  the  input  of  the  preamp.  For  the  indicated  r.rans- 
resistance  and  bandwidth,  a feedback  capacitance  of  less  than 
. 009pF  could  cause  the  receiver  to  oscillate. 


The  enclosure  shown  mounted  to  the  back  of  the  front  panel 
in  Figure  15  contains  all  of  the  uniquely  optoelectronic 
portion  of  the  MTU  or  CMTU.  The  signal  inputs  and  outputs 
from  this  enclosure  are  standard  integrated  circuit  logic 
levels  - either  ECL  or  TTL. 


The  remainder  of  the  MTU  and  CMTU  electronics  was  accom- 
plished using  standard  small  scale  integration  (SSI)  and 
medium  scale  integration  (MSI)  logic  components.  Presently 
there  are  no  large  scale  integration  (LSI)  logic  elements 
capable  of  handling  the  requirements  of  lOMbit/s  or  higher 
data  rates.  Because  of  this,  the  MTU  and  CMTU  logic  requires 
considerably  more  volume  than  is  normally  used  for  the  same 
functions  at  l.OMbit/s. 


The  sync  detection  subsystem  was  constructed  on  two  plug- 
gable circuit  boards.  Ground  plane  PC  board  construction  was 
used  for  these  boards  to  accommodate  the  100MHz  clock  and  ECL 
logic  circuits  required  in  this  subsystem.  The  remaining  four 
subsystems  were  constructed  on  pluggable  wire  wrap  circuit 
boards,  with  the  same  outline  dimension  as  the  sync  detection 
board.  These  six  boards  were  housed  in  a card  cage  occupying 
one  half  of  the  instrument  case.  These  circuit  boards  are 
accessible  through  removal  of  the  rear  panel  of  the  cases. 

The  plug  end  of  the  card  cage  is  shown  on  the  left  side  of  the 
instrument  case  in  Figure  15.  The  other  half  of  the  instru- 
ment case  houses  the  modular  power  supplies,  EMI  filter  and 
blower . 

In  addition  to  the  seven  MTUs  and  one  C.MTU,  Figure  2 
also  shows  three  test  sets,  the  radial  coupler  and  the  fiber 
optic  cable.  The  test  sets  simulate  the  electrical  inter- 
face requirements  of  the  CMTU  and  MTUs. 

The  MTU  Test  Set  simulates  the  function  of  the  SSIU.  The 
MTU  Test  Set  will  either  store  data  received  from  the  MTU  or 
transmit  stored  data  to  the  MTU.  The  SSIU  STATUS  Switch 
controls  the  SSIU  status  bit  in  the  MTU  for  error  checks. 

The  MTU  POWER  Switch  provides  for  remote  control  of  the  MTU's 
power.  The  SSIU  electrical  interface  connector  provides  the 
TTL  level  signals  for  interfacing  to  the  MTU  as  shown  in 
Figure  7. 

The  CMTU  Test  Set  simulates  the  function  of  the  controller 
and  provides  some  tests  on  data  words.  The  CMTU  Test  Set 
interfaces  with  the  CMTU  to  control  the  data  bus  operation 
and  simulate  actual  control  signals,  so  that  the  EMI/EMP 
Data  Bus  System  can  be  exercised  and  tested  using  standard 
test  equipment.  The  CMTU  Test  Set  front  panel  may  be  divided 
into  3 functional  sections.  The  lower  right  section  which 
controls  the  bus  operations,  the  lower  left  section  which  con- 
trols the  bus  status  and  data  words  and  the  upper  section  which 
displays  the  status  of  the  bus  operations. 

The  Bus  Operation  Section  is  made  up  of  four  switches. 
These  are: 

o Transfer  Mode 
o Rate 

o Reset 

o Stop 

The  transfer  mode  switch  controls  the  type  of  command 
used  on  the  bus.  This  is  a three  position  switch.  One  posi- 
tion is  for  data  transfer  from  the  CMTU  to  an  MTU  or  from  an 
MTU  to  the  CMTU.  The  second  position  is  for  data  transfer 
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between  two  MTUs.  In  the  third  or  loop  position,  data  is 
transferred  by  all  three  methods  --  CMTU  to  MTU;  MTU  to  MTU; 

MTU  to  CMTU. 

The  rate  switch  controls  the  number  of  times  a bus  opera- 
tion takes  place.  In  the  SINGLE  position,  the  bus  operation 
happens  only  once.  In  the  CONTINUOUS  position,  the  bus  opera- 
tion is  continuously  repeated.  In  the  STOP  on  ERROR  position, 
the  bus  operation  is  continuously  repeated  until  an  error  is 
detected.  This  error  is  then  displayed. 

The  RESET  switch  is  used  to  start  the  bus  operation.  In 
the  single  mode  the  RESET  switch  starts  one  bus  operation  each 
time  it  is  pressed. 

The  STOP  switch  stops  the  bus  operations. 

The  word  control  section  is  made  up  of  three  rows  of 
thumbwheel  switches.  The  top  row  controls  the  command  word 
in  CMTU  to  MTU  transactions  and  controls  the  transmit  command 
word  in  MTU  to  MTU  transactions. 

The  second  row  of  thumbwheel  switches  controls  the  command 
word  to  the  receive  MTU,  in  MTU  to  MTU  transactions. 

The  third  row  of  thumbwheel  switches  controls  the  data 
words  that  are  to  be  transmitted  by  the  CMTU.  A comparison 
check  is  also  made  against  the  received  data  word  and  this 
data  word  to  check  for  errors. 

The  display  section  displays  the  received  status  word 
from  the  MTU.  It  also  displays  the  received  or  transmitted 
data  words  of  the  CMTU.  The  ERROR  CONDITION  display  indicates 
an  error  has  occurred.  The  TEST  COMPLETE  display  indicates 
the  bus  operation  is  stopped. 

The  rear  panel  of  the  CMTU  Test  Set  provides  the  follow- 
ing output  connectors : 

CMTU  Interface 
Sync 

Error  Count 
Spare 

The  CMTU  INTERFACE  connector  provides  the  TTL  level  inter- 
face to  the  CMTU.  The  SYNC  output  provides  a negative  sync 
signal  to  be  used  by  an  oscilloscope.  The  ERROR  COUNT  output 
provides  an  output  pulse  for  each  error  detected.  This  is 
used  by  a counter  to  totalize  the  error  over  a given  period 
of  time. 
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Testing  and  evaluation  of  the  data  bus  is  accomplished 
using  the  equipment  configuration  shown  in  Figure  16.  Only 
two  MTU  test  sets  are  provided.  Thus,  complete  testing  of 
all  functions  for  all  stations  requires  the  MTU  Test  Sets  to 
be  moved  from  station  to  station.  No  external  data  inputs 
are  provided  at  the  MTU  Test  Set.  All  data  placed  in  the 
MTU  Test  Set  memories  must  be  introduced  via  the  fiber  optic 
data  bus. 

Construction  of  a data  bus  requires  the  use  of  signal 
coupling  devices  which  make  it  possible  for  each  station  to 
receive  signals  from  the  bus  and  transmit  signals  onto  the 
bus.  The  vital  nature  of  the  signal  transactions  on  an  avionic 
data  bus  dictates  that  a strong  emphasis  on  system  reliability 
be  used  in  the  coupler  design.  In  general,  repeater  systems 
are  not  employed  in  data  buses  because  damage  to  one  repeater 
would  interrupt  signal  flow  on  the  entire  data  bus. 

In  an  optoelectronic  data  bus,  the  various  stations  are 
interconnected  with  flexible  fiber  optic  bundles.  The  desired 
signal  coupling  device  should  provide  the  following  functions: 

o A portion  of  the  optical  signal  should  be 
removed  from  the  bus  for  detection, 
o The  undetected  remainder  of  the  optical  signal 
should  be  passed  on  for  distribution  to  the 
other  terminals  on  the  bus. 
o Optical  signals  generated  in  that  terminal 

should  be  coupled  onto  the  bus  and  distributed 
to  the  other  terminals. 


Meeting  these  requirements  provides  fault  isolation  on  the 
optoelectronic  data  bus  so  that  failure  of  one  of  the  stations 
on  the  bus  will  affect  only  that  station  and  will  leave  the 
remainder  of  the  bus  unimpaired.  Two  basic  schemes  have  been 
reported2'3  for  providing  these  functions  in  an  optoelectronic 
data  bus.  One  approach  uses  an  in-line  configuration  in  which 
individual  stations  are  sequentially  interconnected  by  flexi- 
ble fiber  optic  bundles.  The  other  approach  uses  a radial 
configuration  in  which  all  stations  are  connected  by  flexible 
fiber  optic  bundles  to  a centrally  located  mixing  point. 

The  in-line  data  bus  uses  a passive  T coupler4  for  each 
station  on  the  bus,  whereas  the  radial  data  bus  uses  a single 
passive  radial  coupler4.  The  radial  coupler  need  not  be 
located  at  one  of  the  stations  but  can  be  centrally  located 
between  stations  to  reduce  bus  length.  Figure  17  shows  the 
configuration  of  a radial  duplex  data  bus. 
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Figure  16:  EMI/EMP  - Data  Bus  Test  Set  Up 


Since  construction  of  the  radial  coupler  is  of  approxi- 
mately the  same  complexity  as  construction  of  a single  T coupler 
and  the  performance  of  a radial  data  bus  is  superior  to  the 
performance  of  an  in-line  data  bus,  the  radial  data  bus  was 
chosen  for  use  in  this  system.  The  radial  coupler  constructed 
for  this  system  uses  solid  side  arms  and  a square  cross-section 
scrambler  rod.  This  construction  gives  low  loss  and  uniform 
coupling  between  the  various  pairs  of  side  arms.  The  radial 
coupler  is  housed  in  the  bulkhead  mounting  half  of  the  rectangu- 
lar connector  housing  shown  in  Figure  2 in  front  of  the  CMTU 
Test  Set. 

The  cable  half  of  the  rectangular  connector  shown  in 
Figure  2 forms  a pluggable  interface  between  the  eight  fiber 
optic  bundles  and  the  radial  coupler.  The  cable  connector  uses 
the  ITT  Cannon  o-ring  loaded  ferrule.  One  key  feature  of  this 
fiber  optic  connector  developed  by  ITT  Cannon  allows  each  fiber 
bundle  to  be  removed  from  the  connector  with  a simple  rear 
release  tool. 

The  fiber  optic  bundles  used  in  the  system  and  shown  in 
Figure  2 are  plastic  clad  fused  silica  core  fibers  made  by 
Valtec.  The  parameters  of  the  specific  batch  of  fiber  bundle 
used  in  the  system  are  shown  in  Table  2.  Only  37  of  the  42 


Table  2:  Measured  Parameters  of 

Valtec  Fiber  Bundles 


Number  of  fibers 
Average  fiber  diameter 
Average  core  diameter 
Jacket 
Attenuation 
Numerical  Aperture 
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5.6  mils 

4.6  mils 

. 140"OD  Hytrel 
127dB/km  @ 907nm 
0.3 


fibers  in  the  bundle  were  used.  A spectral  response  on  this 
fiber  fundle  is  shown  in  Figure  18.  The  attenuation  between 
800nm  and  850nm  is  less  than  50dB/km  where  the  fiber  is  speci- 
fied by  Valtec.  The  wavelength  of  the  GaAs  LEDs  used  in  the 
data  bus  is  907nm.  At  this  wavelength  the  attenuation  of  the 
Valtec  fiber  is  127dB/km  as  shown  in  Table  2. 

Plastic  clad  fused  silica  core  fiber  was  selected  for  the 
data  bus  because  it  has  a good  combination  of  characteristics: 


■ 'v™  i , - mm 


8000  8200  8400  8600  8800  9000  9200  9400 

o 

Wavelength  (A) 


The  relatively  high  NA  of  0.3  and  large  core 
diameter  gives  good  coupling  at  the  LED/fiber 
optic  interface  combined  with  a signal  band- 
width of  about  110MHz  for  a 100ft  length  of 
fiber  bundle. 


The  rrlatively  low  attenuation  of  127dB/km  at 
907nm  gives  a loss  of  only  3.87dB  in  a 100ft 
length  of  fiber  bundle. 


The  plastic  cladding  and  Hytrel  jacket  gives 
this  fiber  bundle  an  operating  temperature 
range  from  -55°C  to  greater  than  +125°C. 


In  addition,  plastic  clad  fused  silica  core  fiber  made  by 
Schott  in  Europe  has  shown  the  best  reported  nuclear  radia 
tion  hardness  for  both  ionizing  radiation  and  high  energy 
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neutrons5.  This  basic  type  of  fiber  bundle  with  strength 
members  added  is  now  available  from  both  Valtec  and  Galileo 
Electro  Optics  and  should  be  the  fiber  bundle  used  in  most 
future  avionic  data  bus  systems.  It  is  difficult  to  make 
low- loss  terminations  with  this  fiber  bundle.  However,  it 
should  be  possible  to  eliminate  this  deficiency  in  the  near 
future.  This  termination  problem  is  discussed  in  more  detail 
later  in  the  report. 


A single  bundle  of  the  Valtec  fiber  is  used  for  each 
arm  of  the  radial  data  bus  as  shown  in  Figure  2;  the  bundle 
lengths  are  shown  in  Table  1.  Each  of  the  eight  bundles  is 
bifurcated  on  the  station  end  with  19  of  the  37  fibers  going 
to  the  detector  and  18  going  to  the  LED. 

OPTOELECTRONIC  INTERFACE 

Fiber  optic  data  transmission  systems  using  LEDs  and 
photodiodes  are  governed  by  different  design  constraints  than 
those  encountered  in  wire  systems.  Satisfactory  performance 
of  the  fiber  optic  system  requires  that  these  unique  design 
constraints  be  adequately  satisfied  by  the  implemented  design. 
Most  of  the  fundamental  design  constraints  result  from 

o the  unipolar  nature  of  the  optical 
signal,  and 

o the  noise  vs.  frequency  characteristic 
of  the  fiber  optic  receiver. 

Light  emitted  from  an  LED  is  not  coherent  and  must,  there- 
fore, be  treated  as  a photon  flux  or  power5.  Thus,  a modulated 
LED  emits  a time  varying  power  that  has  no  negative  values. 
Because  the  light  output  of  an  LED  can  be  only  zero  or  posi- 
tive, the  Manchester  coded  optical  signal  required  by  MIL-STD- 
1553  is  unipolar  with  its  average  value  equal  to  half  the  peak. 
The  conventional  Manchester  signal  used  in  wire  data  buses  is 
bipolar  with  equal  positive  and  negative  excursions  and  an 
average  value  of  zero.  Figure  19  shows  a comparison  of  bipolar 
and  unipolar  Manchester  signals. 

The  threshold  level  of  the  conventional  bipolar  Manchester 
signal  is  independent  of  the  data  content  and  signal  amplitude, 
however  this  is  not  the  case  for  the  unipolar  Manchester  signal. 
The  unipolar  Manchester  signal  threshold  is  independent  of  data 
content  but  is  dependent  on  signal  level.  For  the  ac  coupled 
unipolar  signal  the  threshold  level  is  the  average  value  of 
the  signal,  which  for  the  Manchester  signal  is  one  half  the 
peak  signal  amplitude  in  the  steady  state  condition.  The 
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operation  of  the  data  bus  however,  does  not  allow  for  the 
steady  state  condition  to  exist  for  very  long.  Transactions 
on  the  bus  gives  rise  to  a range  of  optical  signals  due  to 
differences  in  attenuation  in  the  various  path  lengths.  The 
optical  signal  level  at  any  given  receiver  changes  rapidly  and 
is  interspersed  with  short  dead  times  as  shown  in  Figure  3. 

This  optical  signal  range  (OSR) 6 causes  a serious  problem  in 
an  ac  coupled  receiver  that  is  illustrated  in  Figure  20,  For 
a transaction  with  a near  station,  the  signal  is  large  and 
the  input  coupling  capacitor  charges  up  to  the  average  value 
of  the  signal.  If  this  is  followed  by  a transaction  with  a 
distant  station  where  the  signal  is  small,  the  coupling  capa- 
citor discharges  to  the  new  average  value.  This  signal  is 
difficult  to  decode  as  the  reference  level  in  the  receiver 
must  constantly  change  with  the  incoming  signal  level  changes. 

It  is  now  appropriate  to  consider  the  constraints  resulting 
from  the  noise  vs  frequency  characteristic  of  a fiber  optic 
receiver.  A reverse  biased  p-i-n  photodiode  can  be  represented 
by  a high-Q  capacitor  in  parallel  with  a constant  current 
source;  the  value  of  the  current  is  proportional  to  the  optical 
power  on  the  active  area  of  the  detector.  Since  the  output 
signal  of  the  photodiode  is  a current,  the  signal-to-noise 
ratio  at  the  photodiode/preamp  interface  is  completely  described 
by  the  equivalent  input  noise  current  of  the  amplifier.  Since 
the  photodiode  is  a high-Q  capacitor,  it  is  essentially  free 
of  noise  up  to  moderately  high  frequencies  (£  80MHz) . In- 
vestigation of  various  photodiode/preamp  combinations5  has 
shown  that  the  equivalent  input  value  of  i2/Af  is  not  constant 
with  frequency  but  contains  a significant  nf2  term.  This  "non- 
white" noise  spectrum  means  that  the  receiver  must  have  at  least 
t .vo  poles  in  the  high-frequency  cutoff  characteristics  so  that 
. 'tal  noise  will  be  bounded5.  Another  result  of  the  "non- 
v xt  noise  characteristic  is  that  for  a family  cf  optimized 
preamps,  the  rms  value  of  the  input  noise  current,  i„,  is  pro- 
portional to  the  amplifier  bandwidth.  For  a constant  error 
rate,  the  required  signal  power  on  the  detector  is  proportional 
to  the  amplifier  bandwidth5.  This  means  that  the  lowest  noise 
data  bus  receiver  will  be  achieved  when  the  bandwidth  is  limited 
in  the  preamp.  This  is  different  from  the  usual  situation 
found  in  a wire  system  where  the  noise  spectrum  is  "white"  and 
the  rms  value  of  the  input  noise  current  varies  with  the  square 
root  of  the  amplifier  bandwidth. 

A direct  coupled  receiver  may  be  used  to  overcome  the  ac 
coupled  signal  shift  shown  in  Figure  20.  However,  the  preamp 
bandwidth  constraint  causes  a different  problem  in  the  direct 
coupled  receiver  that  is  illustrated  in  Figure  21.  These 


waveforms  are  typical  for  lOMbit/s  with  a system  bandwidth 
(3dB)  of  10.0MHz.  The  threshold  is  set  to  properly  detect 
the  weak  signal;  however,  stronger  signals  will  not  be  symmetri 
cal  about  the  threshold  and  a strong  signal  12.5  times  larger 
than  the  weak  signal  will  have  no  portion  of  its  waveform  fall 
below  the  threshold  level.  This  deficiency  can  be  overcome  by 
increasing  the  system  bandwidth  to  gi/e  faster  rise  and  fall 
time  on  the  signal  waveforms.  With  faster  rise  time  the 
signal  will  come  closer  to  the  steady-state  "on"  or  "off" 
level  during  each  half  bit  time  and  more  dynamic  range  can 
be  accommodated.  However,  the  increased  bandwidth  will  cause 
a proportional  increase  in  the  input  noise  current  that  will 
seriously  degrade  the  signal-to-noise  ratio  of  the  receiver. 


Figure  21;  Signals  in  a Direct  Coupled  Receiver 


An  additional  problem  in  direct  coupling  is  the  presence 
of  drift  as  a possible  source  of  error.  The  drift  in  an 
optimized  10MHz  preamp  requires  about  2 times  more  minimum 
optical  power5  on  the  detector  than  is  required  with  an  ac 
coupled  receiver  with  the  same  bandwidth. 

This  discussion  has  been  presented  to  describe  some  of 
the  major  problems  and  constraints  that  are  encountered  in  the 


design  and  optimization  of  a fiber  optic  data  bus.  There  are 
several  different  circuit  approaches  that  can  be  used  to  mini- 
mize the  effect  of  these  constraints.  The  only  approach  that 
will  be  described  is  the  on„  used  in  the  construction  of  this 
data  bus. 

The  block  diagram  of  the  receive  optoelectronic  interface 
used  to  solve  the  problem  of  the  optical  unipolar  signal  is 
shown  in  Figure  22  and  consists  of  the  following  sections 

Photodiode 

Preamp 

Postamp 

DC  Restoration 
Buffer  Amp 
Peak  Detector 
Comparitor 
Delay  Detector 

To  provide  for  optimum  S/N  ratio,  the  preamp  and  postamp 
are  ac  coupled  to  eliminate  drift  as  a possible  source  of  error. 
Further,  since  the  direct  coupled  signal  is  easier  to  detect 
than  the  ac  signal,  the  ac  signal  is  restored  again  to  a dc 
level. 

Detection  of  the  dc  restored  signal  is  made  by  the  peak 
detection  circuit  and  the  comparator.  The  peak  detector  sets 
a reference  level  of  1/2  the  peak  incoming  signal.  This 
reference  level  is  provided  to  one  of  the  comparator  inputs 
to  provide  a proper  threshold  for  decoding  of  the  input  signal. 

The  output  of  the  comparator  is  monitored  by  a delay 
detector.  This  delay  detector  monitors  the  end  of  a message  by 
detecting  the  delay  between  transmissions  of  different  terminals 
shown  in  Figure  3.  When  a delay  is  detected,  the  peak  detector 
is  reset  so  that  the  next  message  can  be  detected  even  if  it 
has  the  minimum  value  required  to  give  the  specified  bit  error 
rate.  Figure  5 and  6 show  that  the  longest  delay  (low  state) 
that  can  occur  during  a valid  word  is  two  bit  times.  Thus, 
the  delay  detector  must  be  designed  to  detect  delays  of  three 
bit  times  or  longer;  an  additional  bit  time  is  needed  to  dis- 
charge the  peak  detector.  The  circuit  shown  in  Figure  22 
requires  a delay  between  transactions  of  at  least  four  bit 
times.  The  peak  detector  must  be  capable  of  setting  the  com- 
paritor reference  to  the  proper  value  during  the  first  half  of 
the  invalid  Manchester  bit  shown  in  Figure  5.  Figure  3 shows 
that  a delay  is  always  followed  by  a command  word  or  a status 
word  both  of  which  carry  the  synchronization  waveform  shown  in 


! 


211 


Receive  Optoelectronic  Interface 


Figure  5.  During  a transmission,  th'  peak  detector  will  be 
fully  refreshed  by  the  high  level  potion  of  the  data  sync 
waveform  shown  in  Figure  6,  The  data  sync  occurs  once  in 
each  word.  Therefore,  the  peak  detector  only  has  to  hold 
for  20  bit  times.  It  is  possible  for  some  refreshing  of  the 
peak  detector  to  occur  during  the  high  level  portion  of  any 
bit.  However,  the  bandwidth  limitation  of  the  receiver  tends 
to  give  a smaller  signal  excursion  for  a valid  Manchester  bit 
(1/2  bit  time)  than  for  an  invalid  Manchester  bit  (3/2  bit 
time) . 

I 

An  approximate  error  analysis  has  shown  that  the  3dB 
bandwidth  of  the  receiver  should  be  about  10MHz  for  a lOMbit/s 
data  rate.  This  analysis  assumed  a two-pole  transfer  function 
for  the  receiver  with  the  poles  separated  by  a ratio  of  1.85. 

This  is  the  Spectronics , Inc.  suboptimum  detector  described 
in  Refs.  5 and  7.  An  LED  rise  time  of  15ns  was  also  assumed. 

This  gives  a 10-90%  rise  time  of  35ns  for  the  receiver  alone. 

The  total  system  rise  time  including  LED  and  receiver  is  38ns. 

If  the  receiver  bandwidth  is  increased  beyond  10MHz,  the  error 
rate  increases  due  to  the  increase  in  receiver  noise.  If  the 
receiver  bandwidth  is  reduced  to  less  than  10MHz,  the  error 
rate  increases  due  to  both  an  increase  in  clock  errors  associ- 
ated with  the  sync  detection  circuit  and  improper  functioning 
of  the  peak  detector.  Further  analysis  and  simulation  will  be 
required  to  determine  the  optimum  receiver  bandwidth.  However, 
a receiver  bandwidth  equal  to  the  bit  rate  gives  an  acceptable 
design  for  the  optoelectronic  interface. 

The  preamp  shown  in  Figure  22  has  a transresistance  of 
75Kft  with  a pole  at  12.5MHz  and  the  postamp  has  a voltage  gain 
of  32  with  a pole  at  23MHz.  This  gives  an  overall  transresis- 
tance of  32  x 75Kft=2.4Mft  for  the  receiver.  The  dc  restore, 
buffer  amp,  comparator  and  peak  detector  all  operate  at  a high 
signal  level  with  a voltage  gain  of  one. 

The  reference  level  at  the  input  to  the  comparator  comes 
from  the  peak  detector  and  is  half  (1/2)  the  signal  level. 

However,  to  prevent  errors  from  occurring  in  the  no  signal 
condition,  the  reference  level  is  never  allowed  to  drop  below 
.100  volts.  So,  the  minimum  input  signal  that  can  be  properly 
decoded  is  .200  volts. 

LED  AND  PHOTODIODE 

The  LED  used  in  the  data  bus  is  a planar  GaAs  edge  emitter 
manufactured  by  Spectronics,  Inc.  The  basic  LED  shown  in 
Figure  23  carries  the  part  number  SPX  1775.  The  photodiode 
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Figure  23:  SPX  1775  LED 
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Figure  24:  SPX  1777  Photodiode 


used  is  the  SPX  1777’  it  is  also  made  by  Spectronics,  Inc.  As 
shown  in  Figure  24 , the  package  outline  for  the  photodiode  is 
the  same  as  the  LED.  These  two  components  were  developed  for 
the  Naval  Avionics  Facility  at  Indianapolis8  and  were  designed 
for  coupling  to  fiber  optic  bundles  with  diameter  up  to  .050in. 
The  components  are  also  useful  for  coupling  to  smaller  bundles 
and  single  fiber.  The  coaxial  package  configuration  is  ideal 
for  mounting  in  multi-pin  connectors  and  offers  both  low  series 
inductance  and  a thermal  resistance  less  than  100®C/W.  The 
edge  emitting  wafer  with  optimized  collimating  reflector  pro- 
vides for  a high-efficiency  LED  with  a narrow  beam  angle.  The 
LED  characteristics  are  presented  in  Table  3.  The  photodiode 
is  designed  so  that  the  entire  thickness  of  the  wafer  is  de- 
pleted at  a reverse  bias  of  90V.  Operation  at  full  depletion 
gives  minimum  capacitance,  minimum  series  resistance,  and 
essentially  eliminates  the  slow  tail  response5/8.  The  con- 
densing cone  in  the  cap  gives  a photodiode  responsivity  of 
0.5A/W;  this  value  includes  all  of  the  end  loss  at  the  plug- 
gable photodiode/fiber  optic  interface.  The  photodiode  char- 
acteristics are  presented  in  Table  4. 

The  total  power  output  of  the  LEDs  selected  for  use  on 
the  data  bus  is  2.5  to  3.0mW  at  a bias  current  of  100mA.  These 
LEDs  were  selected  for  high  output  power;  and,  as  a result, 
have  a somewhat  longer  rise  time  than  shown  in  Table  3.  The 
measured  30ns  rise  time  of  these  high-output  LEDs  is  not  ade- 
quate for  the  10MHz  Manchester  data  rate  so  a 2 to  1 speed-up 
network  is  used  in  the  LED  driver.  This  approach  gives  an 
optical  rise  time  of  15ns  or  less  from  the  transmitter.  The 
data  bus  was  designed  to  operate  at  a 66%  efficiency  to  faci- 
litate future  operation  with  a l.OMbit/s  SSIU.  The  "on" 
current  of  the  LED  is  about  200mA  at  a forward  drop  of  about 
1.5V.  Thus,  the  66%  efficiency  of  the  data  bus  coupled  with 
the  50%  duty  cycle  of  the  Manchester  gives  an  overall  duty 
cycle  of  33%  and  an  average  power  dissipation  of  lOOmW  in  the 
LED.  Because  of  this  power  dissipation,  it  is  necessary  to 
heat  sink  the  LED  adequately  to  make  use  of  the  good  thermal 
resistance  characteristics  of  the  LED  package  so  the  junction 
temperature  rise  is  minimized.  For  a lOOmW  power  dissipation, 
the  junction  temperature  will  rise  10°C  above  the  heat  sink 
temperature. 

LED  AND  PHOTODIODE  MOUNTING 

The  LED  and  photodiode  were  mounted  in  a modified  DED 
connector  manufactured  by  ITT  Cannon  Electric  Division.  This 
connector  shown  in  Figure  25  was  modified  by  ITT  Cannon  to 
specifically  house  these  devices  with  the  mating  half  housing 
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Table  3:  SPX  1775  CHARACTERISTICS 
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Description: 

Optical/Electrical  Specifications  0 25 


GaAs  edge  emitting  LED, 
Coaxial  Package 
°C 


Reverse  breakdown  voltage 
§ IR  = lOya 

Forward  voltage  0 Ip  = 100mA 
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CT  0 VR  = IV,  f = 1MHz 
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Min  Max  Typical 
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Table  4:  SPX  1777  CHARACTERISTICS 


Description : 

PIN  Photodiode, 
Coaxial  Package 

Chip  thickness 

.004in  (nominal) 

Active  Area 

•050in  diameter 

Optical/Electrical  Specifications  0 

25°C: 

Min  Max  Typical 

Reverse  breakdown  voltage 

180V  200V 

0 IR  = 10ya 

Dark  Leakage  current 

20na  lna 

0 V = 90V 

Total  capacitance,  VR  = 90V 

4 . 2pF 

0 f = 1MHz  VR  = 30V 

5 . 2pF 

Responsivity  @ X = 907nm 

0.5A/W 

Rise  Time  (10-90%)  0 VR  = 90V 

1.5ns 

Series  Resistance  0 VR  = 90V 

15(2 
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F O INTERFACE 


the  fiber  optics  cables  to  provide  a pluggable  optical  inter- 
face at  the  front  panel  of  the  MTUs  and  CMTU. 

The  LED  and  photodiode  are  first  soldered  into  retaining 
clips.  These  clips  provide  an  electrical  contact  for  the 
anode  of  the  LED  and  detector.  Tnese  device  retaining  clip 
assemblies  are  inserted  into  the  rear  of  the  connector  insert. 

This  insert  is  aluminum  and  is  hard  anodized  to  provide  elec- 
trical isolation  for  the  LED  while  still  providing  a good  heat 
sink.  The  photodiode  is  further  isolated  from  the  anodized 
insert  by  a plastic  cylindrical  insert.  The  anodized  aluminum 
insert  is  connected  to  signal  ground  and  insulated  from  chassis 
ground.  This  arrangement  provides  EMI  shielding  and  prevents 
cross  talk  between  the  transmitter  and  receiver  without  intro- 
ducing a ground  loop. 

The  connector  shown  in  Figure  25  is  connected  to  the  front 
panel  of  the  MTU  (or  CMTU)  with  the  back  section  extending 
into  the  partitioned  RF  enclosure  shown  in  Figure  13.  The 
cable  half  of  the  connector  shown  in  Figure  25  uses  two  ITT 
Cannon  o-ring  ferrules  to  terminate  the  bifurcated  fiber 
optic  bundle.  The  o-ring  is  used  to  take  up  dimensional 
tolerance  variation  at  the  pluggable  interface  and  provide  a 
positive  axial  loading  to  insure  a mechanically  stable  optical 
interface.  The  DED  connector  is  polarized  so  that  the  fiber 
bundle  termination  for  the  LED  always  interfaces  with  the  LED. 

The  fiber  optic  terminations  can  be  removed  from  the  cable 
half  of  the  connector  with  a rear  release  tool. 

LED/DRIVER  INTERFACE 

The  schematic  of  the  LED  drive  circuit  is  shown  in  Figure  26. 
This  circuit  uses  a standard  IC  manufactured  by  American  Micro 
Devices.  The  IC  is  a high-speed  Schottky  quad  line  driver/ 
receiver  capable  of  sinking  100mA  on  each  of  its  four  output 
lines.  This  gives  a total  drive  current  capability  of  400mA. 

The  series  drive  circuit  has  speed-up  drive  capabilities  on 
turn-on  but  does  not  provide  any  drive  current  on  turn-off. 

A resistor  is  added  in  parallel  with  the  LED  to  provide  a 
turn-off  current  source.  The  LED  driver  is  constructed  on  a 
ground  plane  PC  board  and  mounted  in  the  partitioned  RF 
enclosure  behind  the  front  panel  as  shown  in  Figure  13. 

This  series  LED  drive  circuit  draws  400mA  peak  current 
pulses  from  the  supply  line.  In  order  to  prevent  cross-talk 
in  other  circuits,  the  supply  line  is  decoupled  from  the  LED 
driver  by  a parallel  "T"  network  shown  in  Figure  13.  The  drive 
circuit  supplies  345mA  of  forward  current  to  the  LED  during 
initial  turn-on.  This  current  decays  back  to  175mA  within  the 
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50ns  minimum  pulse  width.  The  current  through  the  turn-off 
resistor  is  55mA. 

PHOTODIODE/PREAMP  INTERFACE 

Figure  27  shows  a schematic  of  the  preamp  used  in  the 
data  bus.  The  preamp  uses  a monolithic  transistor  array  manu- 
factured by  RCA.  The  device  is  a CA3127E  and  contains  5 
transistors.  These  transistors  have  an  f.  of  1.1GHz  @ Ip  = lma 
and  VCE  = 5 volts. 

The  basic  circuit  is  a trans impedance  (current  mode  input) 
design  having  a cascode  input  stage  and  shunt  feed-back.  The 
cascode  input  reduces  the  Miller  effect  capacitance  due  to  the 
collector-base  capacitance.  Three  transistors  are  required  to 
build  this  amplifier,  so  the  two  spare  transistors,  Ql  and  Q4, 
are  used  as  reference  diodes,  to  provide  required  dc  levels. 
This  simplifies  construction  by  reducing  component  count. 

The  preamp  is  constructed  on  a separate  circuit  board  and  is 
mounted  on  the  back  of  the  front  panel  in  one  half  of  the 
partitioned  RF  enclosure  shown  in  Figure  13.  This  allows  the 
photodiode  to  be  connected  directly  to  the  preamp  which  re- 
duces stray  pick  up  and  provides  good  EMI  protection. 

The  bias  current  for  Q3  was  optimized  for  the  10MHz  re- 
ceiver bandwidth  using  the  procedures  described  in  References 
5 and  7.  The  optimum  bias  current  for  Q3  is  200yA  and  the  rms 
value  of  the  input  noise  current  is  7.1nA.  A number  of  compen- 
sating effects  inherent  in  the  amplifier  design  makes  the  equi- 
valent input  noise  current  essentially  independent  of  tempera- 
ture. 


The  total  transresistance  of  2.4MJ2  gives  an  rms  noise 
voltage  at  the  comparitor  (see  Figure  22)  of 

e = i (2.4M&) 
n n 

= 17mV 


The  minimum  detectable  signal  of  200mV  at  the  comparitor  is 
provided  by  a photodiode  signal  current  of 


200mV 

2.4Mfi 


83 . 3nA 


For  a detector  responsivity  of  0.5A/W,  this  photodiode  signal 
current  is  produced  by  an  optical  power  of  167nW  from  the 
fiber  optic  bundle. 


LED/FIBER  OPTIC  INTERFACE 


Figure  28  shows  a plot  of  optical  power  density  (irradiance) 
as  a function  of  position  along  the  diameter  of  an  SPX  1775 
LED  package  for  three  values  of  NA.  The  scan  was  made  at  the 
surface  of  the  glass  in  the  cap.  The  peak  irradiance  of  the 
LED  is  contained  in  an  annular  ring  37  mils  in  diameter  and  10 
mils  wide.  Thus,  for  a fiber  bundle  containing  an  insuffi- 
cient number  of  fibers  to  fill  the  entire  45  mil  aperture,  the 
best  coupling  can  be  achieved  by  placing  as  many  of  the  fibers 
as  possible  in  a 37  mil  diameter  annular  ring. 

For  the  Valtec  fibers  described  in  Table  2,  up  to  20  of 
the  fibers  can  be  located  with  their  centers  on  a 37  mil 
diameter  circle.  Therefore,  18  or  19  fibers  can  be  located 
in  the  annular  ring  with  a small  amount  of  dead  space.  Figure  29 
shows  a photograph  of  an  annular  termination  of  19  fibers.  One 
of  the  fibers  is  dark  indicating  that  it  is  not  included  in  the 
37  fiber  termination  at  the  radial  coupler.  This  particular 
batch  of  Valtec  fiber  had  an  unusually  large  variation  in  fiber 
diameter. 

Detailed  calculations  based  on  the  spot  scan  data  of 
Figure  28  show  that  18.6%  of  the  total  LED  output  power  should 
be  coupled  to  the  18  Valtec  fibers  in  a ring  termination.  This 
corresponds  to  a calculated  coupling  loss  of  7.3dB;tests  per- 
formed on  the  8 fiber  bundles  terminated  for  the  LED  inter- 
face show  a measured  loss  of  10.5dB.  This  is  3.2dB  more  than 


Figure  29:  Annular  Ring  Termination 
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the  calculated  coupling  loss.  Table  5 shows  calculated  and 
measured  coupling  loss  for  the  SPX  1775  LED  coupled  to  various 
types  of  fiber  optic  bundle.  The  measured  and  calculated 
values  all  agree  except  for  the  Valtec  plastic  clad  fused 
silica  core  fiber.  This  3.2dB  excess  loss  in  the  Valtec 
termination  is  believed  to  be  due  to  the  mechanical  char- 
acteristics of  the  plastic  cladding  layer  on  the  individual 
i bers.  The  thickness  and  softness  of  this  plastic  layer 
combine  to  give  inadequate  mechanical  support  for  the  fibers 
during  the  polishing  operation 


Table  5: 

SPX  1775  LED/Fiber 

Optic  Coupling 

Factors 

Bundle 

No.  of 

Calculated  i 

Measured 

Type 

Fibers 

Factor 

Factor 

Galileo* 

285 

-3 . 7dB 

-3. 4dB 

Rank 

96 

-5 . 5dB 

-5. 6dB 

Valtec 

18 

-7 . 3dB 

-10. 5dB 

Corning 

19 

-13 . OdB 

-12 . 7dB 

*non-ring  termination 

PHOTODIODE/FIBER  OPTIC  INTERFACE 

The  19  fibers  for  coupling  to  the  SPX  1777  photodiode  were 
terminated  in  a 28  mil  hexagonal  pattern  as  shown  in  Figure  30. 


Figure  30:  Hexagonal  Array  Termination 
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This  28  mil  bundle  interfaces  with  the  50  mil  detector  with 
minimal  losses.  The  photodiode  was  designed  for  coupling  to 
fiber  bundles  as  large  as  50  mil  in  diameter;  therefore,  the 
coupling  factor  would  have  been  the  same  if  the  annular  ring 
termination  shown  in  Figure  29  had  also  been  used  for  the 
photodiode/fiber  optic  interface.  Two  different  types  of 
terminations  for  the  LED  and  photodiode  interfaces  are  not 
necessary.  The  ring  and  hexagonal  terminations  are  visible 
in  Figure  25. 

The  responsivity  of  the  SPX  1777  photodiode  is  measured 
using  a fiber  optic  bundle.  Therefore,  the  0.5A/W  responsivity 
of  this  component  includes  the  interface  losses  and  no  addi- 
tional coupling  factor  needs  to  be  included  for  the  photodiode/ 
fiber  optic  interface. 

RADIAL  COUPLER 

The  radial  coupler  constructed  for  this  data  bus  uses 
solid  side  arms  and  a square  cross-section  scrambler  rod.  It 
is  housed  in  a modified  rectangular  connector  housing  as  shown 
in  Figure  31. 

The  nine  square  side  arms  form  a 3 by  3 square  array. 

This  interfaces  with  the  square  scrambler  rod  to  form  an  inter- 
face with  no  void  space  as  with  round  rods  or  fibers.  The 
only  packing  fraction  loss  at  this  interface  is  the  area  loss 
due  to  cladding  on  the  side  arms  and  the  area  loss  due  to  mech- 
anical misalignment. 

To  form  an  interface  with  each  fiber  bundle  on  an  indivi- 
dual basis  each  side  arm  makes  a 90°  bend.  The  90°  bends  are 
spaced  laterally  to  allow  for  the  desired  clearance  between 
adjacent  side  arms. 
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ITT  Cannon  Electric  Division  modified  their  DPK  connector 
to  house  this  radial  coupler  design.  Figure  32  shows  the 
assembly  drawing  of  this  connector  with  the  radial  coupler  piece 
parts.  Housing  the  radial  coupler  in  a multicontact  connector 
offers  several  advantages  over  other  designs.  These  are: 


I 


o Reduction  in  physical  size 

o Easily  accessible  and  pluggable  interfaces 

o Proven  reliable  housing 
o Minimum  retooling  for  production 
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The  dielectric  mirror  used  at  the  end  of  the  scrambler  rod  is 
no  called  out  in  Figure  32, 


The  square  side-arm  radial  coupler  was  evaluated  by  intro- 
ducing a constant  optical  input  successively  into  each  of  the 
nine  arms  of  the  coupler  and  measuring  the  output  of  each  of  the 
remaining  eight  arms.  The  results  of  this  test  are  summarized 
in  Table  6.  The  horizontal  rows  correspond  to  the  percent 
transmission  measured  at  each  of  the  eight  optical  ports  with 
an  input  into  the  port  indicated  by  the  dashed  line.  The 
vertical  columns  represent  the  range  of  output  signals  at  each 
arm  when  light  is  coupled  into  each  of  the  other  eight  arms. 

The  optical  signal  range  (OSR) 6 for  each  of  the  arms  is  given 
at  the  bottom  of  each  column. 


Table  6:  Percent  Transmission  Between 


Radial  Coupler 

Arms 

Arm 

1 

2 

3 

4 

5 

6 

7 

8 

9 

1 

— 

4.17 

4.38 

3.94 

4.42 

4.00 

4.17 

4.23 

4.06 

2 

3.85 

4.58 

3.79 

4.58 

4.52 

4.04 

4.23 

4.46 

3 

4.19 

4.38 

— 

3.5 

4.08 

4.46 

3.62 

3.83 

4.62 

4 

3.85 

3.81 

3.75 

— 

3.79 

3.42 

3.67 

3.65 

3.60 

5 

4.19 

4.23 

4.13 

3.75 

— 

3.94 

4.13 

4.23 

4.33 

6 

3.65 

3.90 

4.27 

3.13 

3.90 

— 

3.65 

3.79 

4.37 

7 

3.53 

3.50 

3.27 

3.46 

3.90 

3.46 

— 

4.52 

4.23 

8 

3.67 

3.65 

3.63 

3.46 

4.04 

3.85 

4.40 

— 

4.58 

9 

3.69 

4.00 

4.04 

3.56 

4.52 

4.60 

4.42 

4.73 

— 

OSR(dB) .60 

. 98 

1.46 

1.00 

. 82 

1.28 

.88 

1.12 

1.08 

The  average  transmission  between  pairs  of  arms  on  the 
radial  coupler  is  4.00%  or  a coupling  factor  of  -13.98dB. 

The  theoretical  power  division  loss  of  a 9 arm  coupler  is  1/9 
or  11.1%;  the  theoretical  coupling  factor  is  -9.54dB.  The 
difference  between  the  theoretical  and  measured  transmission 
is  the  loss  in  the  coupler. 

coupler  loss  = 13.98dB  -9.54dB 
= 4 . 44dB 


The  lowest  coupling  factor  was  measured  for  input  on  arm  6 
and  output  on  arm  4;  the  coupling  factor  is  -15.04dB.  The 


largest  coupling  factor  was  measured  for  input  on  arm  9 and 
output  on  arm  8;  the  coupling  factor  is  -13.25dB.  The  maxi- 
mum OSR  in  a single  side  arm  was  1.45dB  measured  in  arm  3; 
the  minimum  OSR  is  0.60dB  measured  in  arm  1,  The  maximum 
OSR  for  the  entire  coupler  is  1.79dB  as  determined  by  the 
difference  between  the  highest  and  lowest  coupling  factors. 

After  the  back  shell  is  put  into  place  in  the  radial 
coupler,  the  internal  glass  parts  are  potted.  This  provides 
good  protection  from  physical  and  thermal  shock  as  well  as 
offering  a good  environmental  seal. 

The  optical  parts  of  the  coupler  should  always  be  made 
from  the  same  or  similar  materials  as  those  used  in  the  fiber 
optic  bundles.  This  insures  that  the  NA  of  the  coupler  will 
match  that  of  the  fiber.  If  this  design  rule  is  followed, 
the  coupler  should  always  have  environmental  and  nuclear 
hardening  characteristics  that  are  compatible  with  the  rest 
of  the  data  bus  system. 

The  performance  of  radial  couplers  can  be  improved  as 
more  experience  is  gained  in  their  construction.  The  loss 
can  probably  be  reduced  to  l-2dB  and  the  OSR  to  0.1-0.3dB. 

RADIAL  COUPLER/FIBER  OPTIC  INTERFACE 

The  Cannon  DPK  connector  was  used  as  the  pluggable  inter- 
face between  the  radial  coupler  and  the  fiber  bundles  as  shown 
in  Figure  2.  Each  of  the  fiber  optics  termination  ferrules  is 
a removable  contact  for  the  connector.  The  contact  floats  in 
the  connector  as  the  coupler  half  provides  the  alignment  for 
each  contact.  The  contacts  are  o-ring  loaded  to  provide  a 
means  to  take  up  axial  tolerances  in  mating  of  the  two  connector 
halves . 

The  37  fibers  in  each  of  the  eight  fiber  bundles  are 
terminated  in  a hexagonal  pattern  using  a circular  ferrule. 

Even  though  the  solid  side  arms  of  the  coupler  are  square  in 
cross  section,  a circular  ferrule  was  used  so  that  no  keying 
for  angular  alignment  of  the  ferrules  would  be  required  in  the 
connector.  The  use  of  circular  ferrules  at  the  coupler/fiber 
optic  interface  inserts  an  extra  transmission  loss  of  -1.05dB 
(tt/4)  when  light  is  brought  out  of  the  coupler  to  a receiving 
fiber  bundle.  Based  on  the  data  in  Table  2,  the  packing 
fraction  for  37  Valtec  fibers  in  a circular  ferrule  is  0.5 
or  -3 . OdB.  Therefore,  the  calculated  interface  coupling 
factor  at  an  output  port  of  the  radial  coupler  is  -4.05dB. 
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No  packing  fraction  loss  is  encountered  at  the  entrance 
port  of  the  coupler  because  the  circular  ferrule  fits  inside 
the  dimension  of  the  square  side  arm  on  the  coupler.  At  the 
input  port  the  only  expected  loss  is  -0.15dB  due  to  front  sur- 
face reflection  at  the  coupler/fiber  optic  interface. 

The  total  expected  transmission  loss  at  the  coupler/fiber 
optic  interface  is  -4.2dB.  However,  the  extra  termination 
loss  encountered  previously  at  the  LED/fiber  optic  interface 
(see  Table  5)  can  add  from  2dB  to  6dB  extra  loss  at  the  coupler/ 
fiber  optic  interface. 

MAXIMUM  ALLOWABLE  ATTENUATION 

The  maximum  allowable  attenuation  of  the  fiber  optic  data 
bus  can  be  calculated  from  the  known  power  output  of  the  LEDs 
and  the  sensitivity  of  the  receivers.  The  LEDs  were  selected 
for  2.5  to  3.0mW  output  at  100mA  and  operated  at  a current 
drive  of  175mA.  Thus,  the  nominal  LED  power  is 

= 3mW  = 5 . 25mW 

o 100 

For  a minimum  signal  voltage  of  200mV  at  the  comparitor,  the 
input  to  one  of  the  photodiodes  is  167nW.  The  ratio  of  these 
two  power  levels  is  3. 8x10” 5 which  gives  a maximum  allowable 
optical  attenuation  of  45dB  for  the  lOMbit/s  data  rate. 

This  maximum  allowable  attenuation  can  be  allocated  in 
many  different  ways.  However,  if  the  system  is  to  perform 
satisfactorily,  the  sum  of  all  sources  of  attenuation  must  be 
less  than  45dB. 

SYSTEM  EVALUATION 

Measurements  taken  on  the  completed  optical  bus  show  the 
maximum  attenuation  between  different  arms  of  the  bus  to  be 
42dB.  The  minimum  attenuation  was  34dB  with  the  average  being 
38dB.  The  measured  OSR  of  the  bus  is  8.0dB.  These  measure- 
ments were  taken  using  two  different  methods. 

The  first  used  a single  light  emitting  diode  to  inject  a 
signal  into  each  of  7 arms  of  the  optic  bus  while  the  signal 
was  monitored  at  the  remaining  arm.  The  second  method  used 
the  signal  output  of  each  postamp  while  each  of  the  remaining 
stations  are  transmitting.  Both  methods  are  in  good  agreement, 
so  the  second  method  is  considered  here,  as  it  represents  a true 
picture  of  actual  bus  operation. 
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A calculated  value  of  the  total  optical  attenuation  ex- 
pected in  the  data  bus  is  developed  in  Table  7.  Comparison 
to  measured  values  shows  an  excess  loss  of  2 . 3dB  to  5,5dB. 

Table  7 : Total  Optical  Attenuation 


Attenuation  Source 

Min 

Max 

Fiber  Bundle  - 20ft  to  100ft 

0 . 8dB 

3 . 9dB 

Coupler  Transmission 

13 . 3dB 

15.  OdB 

Coupler /Fiber  Optic 

4 . 2dB 

4. 2dB 

LED/Fiber  Optic 

10 . 5dB 

10 . 5dB 

Photodiode/Fiber  Optic 

O.OdB 

O.OdB 

Bifurcation  Loss  (19/37) 

2 . 9dB 

2 . 9dB 

Calculated  Total 

31. 7dB 

36 . 5dB 

Measured  Total 

34 . OdB 

42. OdB 

Difference 

2 . 3dB 

5 . 5dB 

This  excess  loss  was  determined  to  come  from  the  termination 
problem  associated  with  the  plastic  clad  fused  silica  core 
fiber  and  shows  up  at  the  coupler/fiber  optic  interface.  The 
LED/fiber  optic  coupling  factor  has  another  3.2dB  of  this 
excess  loss  included  in  the  10.5dB  value  recorded  in  Table  7. 
Thus,  elimination  of  the  excess  loss  in  the  fiber  optic 
terminations  would  reduce  the  maximum  value  of  total  optical 
attenuation  by  8.7dB.  A 6.0dB  reduction  in  optical  attenua- 
tion would  allow  the  lOMbit/s  data  bus  to  be  expanded  to  32 
stations. 

A calculated  value  of  the  optical  signal  range  (OSR)  is 
developed  in  Table  8.  Comparison  to  the  measured  value  shows 
an  excess  OSR  of  2.67dB.  This  excess  OSR  is  easily  accounted 
for  in  the  variation  of  the  excess  termination  loss  associated 
with  the  plastic  clad  fused  silica  core  fiber. 

Measurements  were  made  in  the  postamp  and  signal  condi- 
tioning section  to  use  in  calculating  the  performance  of  the 
receiver.  The  signal  levels  measured  at  the  input  of  the 
comparitor  (see  Figure  22)  are: 

Maximum  Signal  2.5V  p-p 

Minimum  Signal  400mV  p-p 

Noise  Voltage  17mV  rms 


,r  — • --- — 


231 


Table  8:  Optical  Signal  Range 


OSR  Source  Value 

Radial  Coupler  1.46dB 

Fiber  Bundle  -20ft  to  100ft  3.10dB 

LED  Matching  . 77dB 

Calculated  Total  5.33dB 

Measured  Total  8.0  dB 

Difference  2.67dB 


The  minimum  and  maximum  signal  voltage  is  in  agreement  with 
the  observed  8.0dB  value  of  OSR.  Since  the  comparitor  refer- 
ence level  is  never  allowed  to  drop  below  lOOmV,  the  minimum 
input  signal  that  can  be  properly  decoded  is  200mV.  Thus,  the 
minimum  observed  signal  is  a factor  of  two  larqer  than  the 
minimum  acceptable  signal.  This  is  in  agreement  with  the 
3dB  difference  between  the  maximum  observed  attenuation  and 
the  maximum  allowable  attenuation. 

When  calculating  signal-to-noise  voltage  ratio  at  the 
input  of  the  comparitor,  the  signal  voltage  is  taken  as  the 
deviation  of  the  signal  from  the  reference  threshold  value. 

The  peak  detector  sets  the  threshold  at  half  the  peak-to-peak 
value  of  the  signal  voltage.  Thus,  the  useful  signal  is  half 
the  peak-to-peak  value.  For  the  minimum  signal  of  400mV  p-p 
the  useful  signal  is  200mV  and  the  signal-to-noise  voltage 
ratio  is 


S/N  = 


200mV 

17mV 


= 11.76 


For  the  delay  time  between  transactions  on  the  data  bus  the 
S/N  is  half  the  above  value  because  the  reference  level  never 
drops  below  lOOmV.  The  no  signal  condition  gives  S/N  = 5.88 
which  represents  the  worst  case  S/N  at  the  comparitor  input. 
This  is  close  to  the  S/N  = 5.62  required  for  a bit  error  rate 
of  10-8,  see  Ref.  7.  However,  the  sync  and  data  formats  re- 
quired in  the  digital  electronics  makes  the  probability  of  an 
error  condition  occurring  in  the  off  condition  nearly  non- 
extent. Therefore,  the  worst  case  signal  to  noise  of  11.76 
to  1,  is  realized  when  the  minimum  signal  is  received. 


With  no  clock  errors  or  timing  jitter,  the  worst  case  S/N 
would  give  a calculated  bit  error  rate  of  6xl0-32.  However, 
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in  the  actual  system,  this  calculated  error  rate  will  never 
be  achieved.  The  actual  signal-to-noise  in  the  system  will 
be  less  because  the  data  will  not  always  be  strobed  when  the 
signal  is  at  its  peak.  This  is  due  to  clock  errors  that  occur 
in  the  clock  recovery  schemes  necessary  in  an  asynchronous  data 
bus.  - 


An  accurate  measurement  of  the  bit  error  rate  of  the  data 
bus  system  has  not  yet  been  determined  due  to  the  time  avail- 
able and  the  number  of  combinations  of  bus  operation.  To 
give  an  example,  there  are  56  ways  for  transmission  to  occur 
between  two  of  the  eight  terminals  provided  the  way  the  bus 
is  connected  is  not  included.  If  the  possible  number  of  bus 
connection  combinations  are  included,  there  are  2,257,920 
possible  combinations  of  different  operations  that  can  occur 
on  the  bus.  However,  the  connection  of  the  data  bus  is  not 
expected  to  have  much  effect  on  the  operation  of  the  data  bus 
because  the  OSR  of  the  bus  is  low.  The  measurements  made  on 
the  bus  so  far  show  the  bit  error  rate  to  range  from  5 x 10-9 
to  1 x 10-11.  This  verifies  the  attainment  of  the  10"8  bit 
error  rate  specified  tor  the  system. 

Testing  of  the  data  bus  system  is  performed  using  the 
arrangement  of  equipment  shown  in  Figure  16.  Errors  that 
occur  in  the  bus  operation  can  be  displayed  in  the  status  and 
data  displays  by  operating  the  bus  in  the  stop  on  error  mode. 
In  this  mode  the  bus  will  operate  in  the  continuous  mode  until 
an  error  condition  is  detected.  At  this  time  bus  operation  is 
stopped  and  the  error  displayed  in  either  the  status  word 
display  or  the  data  word  display. 

To  totalize  errors,  the  bus  is  operated  in  the  continuous 
mode  and  a counter  is  connected  to  the  error  count  output  of 
the  CMTU  Test  Set.  Errors  are  counted  over  a period  of  time 
to  give  a good  average  of  the  bit  error  rate.  A bit  error 
rate  of  1 x 10-8  will  give  an  average  of  four  (4)  errors  per 
minute. 

CONCLUSIONS 

A fiber  optic  data  bus  has  been  designed,  fabricated  and 
tested  which  uses  the  protocol  and  organization  set  forth  in 
MIL-STD-1553 (USAF ) . The  data  bus  has  a length  of  100ft  and 
uses  a data  rate  of  lOMbit/s  for  the  purpose  of  demonstrating 
the  speed  capability  of  the  fiber  optic  medium.  However,  the 
fiber  optic  data  bus  is  not  limited  to  the  higher  data  rate. 

A l.OMbit/s  fiber  optic  data  bus  could  be  expanded  to  32 
stations  using  presently  available  components. 


The  demonstrated  performance  of  this  system  proves  that 
the  key  features  and  requirements  of  MIL-STD-1553  are  com- 
patible with  fiber  optic  data  transmission  techniques.  The 
data  bus  system  uses  MIL-type  rectangular  connectors  for  the 
radial  coupler,  component  mounts  and  pluggable  fiber  optic 
interfaces.  The  LEDs,  photodiodes,  LED  drivers,  amplifiers 
and  fiber  bundles  are  all  capable  of  operation  over  the 
temperature  range  -55?C  to  +125°C.  The  LEDs  and  photodiodes 
are  hermetically  sealed  units  developed  for  ultimate  MIL 
approval.  The  fiber  bundles  are  of  the  plastic  clad  fused 
silica  core  construction.  This  basic  type  of  fiber  bundle 
shows  the  best  reported  nuclear  hardness  for  both  ionizing 
radiation  and  high  energy  neutrons. 

The  data  bus  uses  a radial  configuration  with  a centrally 
located  passive  optical  coupler.  The  radial  coupler  constructed 
for  the  data  bus  has  a loss  of  4.44dB  and  a worst  case  optical 
signal  range  of  1.46dB.  With  further  effort,  the  coupler  loss 
can  be  reduced  to  l-2dB  and  the  OSR  can  be  reduced  to  0.1-0.3dB. 

The  data  bus  was  implemented  using  standard  SSI  and  MSI 
logic  components.  Presently  there  are  no  LSI  logic  elements 
capable  of  handling  the  requirements  of  lOMbit/s  or  higher 
data  rates.  Further  developments  will  be  needed  in  the  area 
of  high  speed  LSI  logic  elements  to  realize  high  speed  data 
terminals  with  the  same  physical  sizes  obtainable  in  the  lower 
data  rate  systems. 

This  program  identified  and  quantified  a termination 
problem  with  the  plastic  clad  fused  silica  core  fiber  bundle. 
Solution  of  this  problem  will  reduce  the  optical  attenuation 
by  8.7dB  and  allow  the  lOMbit/s  bus  to  be  expanded  to  32  stations. 
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ABSTRACT 

A communications  and  Data  Handling  (C&DH)  Test  Bed  has  been  designed  to  satisfy 
requirements  imposed  by  low  cost  modular  spacecraft  (S/C).  This  Test  Bed  is 
comprised  of  three  equipments;  a Ground  Station  providing  remote  control, 
the  C&DH  module,  and  a simulated  Attitude  Control  System  representing  one  of 
many  S/C  subsystems.  All  S/C  communications,  internal  and  external,  are 
synchronized  and  controlled  by  the  C&DH  Module,  thus  the  requirement  of 
redundancy  within  the  Module  to  ensure  fault-tolerant  operation.  The  module 
consists  of  an  18  bit  computer  (with  an  I/O  interface)  which  provides 
computational  support  for  S/C  subsystems,  a telemetry  format  generator  for 
fetching  S/C  data  for  relay  to  the  ground,  a Command  Decoder  for  decoding  and 
routing  ground  commands,  a Remote  Decoder  Mux  which  serves  as  the  sole 
communications  interface  for  each  S/C  subsystem,  and  a bi-directional  Party 
Line  Bus  pair  for  linking  the  Module  with  S/C  subsystems.  The  commands  and 
data  types,  transferred  over  the  Party  Line  Bus  Pair  between  the  module  and 
the  Remote  Decoder  Muxes , and  the  time  multiplexing  of  commands  from  multiple 
sources  are  described.  All  three  equipments  have  been  constructed  and  checked 
out  by  means  of  diagnostic  test  programs. 
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A MODULAR  S/C  C&DH  SYSTEM 


■ 


1.  INTRODUCTION 

A continuing  primary  objective  in  our  nation's  space  activities  is 
cost  reduction.  One  significant  opportunity  for  achieving  this  goal  is  to 
assign  more  autonony  to  the  S/C  by  computerization  and  improved  data  systems, 
thus  reducing  costly  ground  support  operations.  Another  is  hardware  standard- 
ization thru  modularity  that, while  minimizing  performance  compromises  permits 
tailoring  the  hardware  to  a wide  variety  of  requirements.  The  use  of  computers 
centralizes  the  S/C  control  functions  and  reduces  dedicated  control  system 
Hardware.  Modularity  dictates  an  ease  of  expanding  S/C  hardware  without  a high 
initial  overhead  penalty.  However  both  computer  centralization  and  modularity 
are  requirements  that  are  more  practically  satisfied  by  time  shared  party 
line  buses  than  by  multi-wire  dedicated  communication  links. 

One  aspect  of  General  Electric's  many  space  activities  is  high  precision 
Attitude  Control  Systems  (ACS)  which  control  the  three-axis  orientation  of  S/C* 
General  Electric  Space  Division  has  developed  a S/C  Communications  & Data 
Handling  Test  Bed  in  order  to  verify  the  detailed  design  of  an  ACS  system, 
composed  of  control  hardware  and  a control  algorithm  resident  in  a shared  S/C 
central  computer,  and  to  establish  compatible  data  bus  interfaces.  This  test 
bed  activity  required  that  the  Party  Line  Bus  Communications  link  between  the 
computer  and  the  ACS,  as  well  as  a varying  number  of  other  S/C  subsystems 
serviced  by  the  central  computer,  be  first  designed  and  constructed.  Require- 
ments that  influence  the  Data  Bus  Design  are  redundancy  permitting  fault 
tolerance,  ease  of  remote  maintenance  permitting  automated  removal  and  replace- 
ment, and  dc  isolation. 

2.  TEST  BED  DESCRIPTION 

The  S/C  Communications  Test  Bed  is  illustrated  in  the  block  diagram  of 
Figure  1.  It  consists  of  three  computer  controlled  systems: 

o SDS-910  computer  performing  the  uplink/downlink  communications  functions 
of  a ground  station. 

o Vehicle  dynamics  simulator  consisting  of  a SDS-9 30/Beckman  hybrid  com- 
puter programmed  to  represent  the  Attitude  Control  System. 

o The  C&DH  module  consisting  of  a computer  and  special  purpose  peripheral 
components  that  control  communications  with  the  multiple  S/C  subsystems. 

The  spacecraft  components  of  this  test  bed,  the  Vehicle  f namics  Simulator 
and  the  C&DH  Module,  form  an  autonomous  system  that  normally  operates  indepen- 
dently of  the  Ground  Station  Computer.  Communications  between  these  two 
components  are  accomplished  by  the  two  party  line  buses  . The  up  and  downlink 
communications  allow  ground  station  personnel  to  change  the  operating  mode  of 
the  two  spacecraft  components  and  to  monitor  its  operations. 
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The  physical  layout  of  the  three  test  bed  racks  and  the  components  comprising 
each  rack  are  illustrated  in  Figure  2.  The  C&DH  rack  communicates  with  each  of 
the  other  racks  by  100  foot  cable  pairs,  each  cable  o',  the  pair  permitting 
unidirectional  serial  digital  communications.  The  uplink  and  downlink  cables 
are  the  hardwire  equivalent  of  the  dedicated  RF  command/telemetry  links;  for 
Test  Bed  purposes  baseband  signal  coding  is  employed.  The  command  and  Data 
Party  Line  Buses  allow  the  C&DH  Module  to  control  and  monitor  the  status  of  all 
S/C  subsystems. 

2. 1 C&DH  MODULE 

The  C&DH  Module  is  the  crossroads  of  all  S/C  communications,  linking 
the  ground  station  with  the  functional  subsystems  of  the  S/C.  The  C&DH 
module  consists  of  six  major  components: 

o Central  Command  Decoder  (CCD)  - checks  all  uplink  transmissions  and 
routes  them  to  their  designated  destinations. 

o Telemetry  Format  Generator  (TFG)  - synchronizes  the  transfer  of  all 
commands  and  data  on  the  party  line  buses  linking  the  S/C  subsystems; 
distributes  data  received  from  the  party  line  bus;  generates  timing 
pulses  synchronizing  operation  of  all  C&DH  components. 

o Advanced  On-Board  Processor  - provides  data  processing  and  computational 
support  for  S/C  subsystems. 

o Special  1/0  (S10)  for  the  AOP  - implements  all  AOP  I/O  transfers. 

o Remote  Decoder  Mux  (RDM)  - implements  all  party  line  bus  communications 
for  its  associated  S/C  subsystem  (C&DH  module  also  requires  a RDM) 

2 . 2 TEST  BED  COMMUNICATIONS 

The  S/C  communication  functions  executed  by  the  C&DH  module  utilize  the 
internal  party  line  buses  for  servicing  the  S/C  subsystems,  and  the  dedicated 
up  and  downlinks  for  the  ground  station  control.  The  commands  and  data  trans- 
ferred over  each  of  the  communications  links,  and  the  send/receive  components 
are  listed  in  Tables  I & II. 

3.  PARTY  LINE  BUSSES 

The  Command  Party  Line  Bus  links  the  S/C  subsystems  with  the  multiple  C&DH 
command  sources  - the  AOP,  TFG,  and  CCD.  Scheduling  access  of  these  command 
sources  to  the  Commend  Party  Line  Bus  is  performed  by  the  TFG.  Each  command 
sent  on  this  bus  is  monitored  by  each  RDM  and  is  executed  by  the  addressed  ROM. 
Each  RDM,  which  does  not  initiate  any  action  without  first  being  commanded, 
cannot,  therefore,  communicate  directly  with  another  RDM;  each  RDM  operates 
in  a slaved  capacity. 
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REQUESTED  DATA  ADVANCED  ON-BOARD  | DATA  RETURNED  IN  RESPONSE  TO 

PROCESSOR  DATA  REQUEST  CMOS 


Three  command  types  are  executed  by  each  RDM: 

o Pulse  commands  which  activate  a single  discrete  relay  or  flip-flop 

o Serial  magnitude  commands  which  load  16  bit  data  words  into  subsystem 
shift  registers. 

o Telemetry,  data  request  commands  which  designate  data  channels  to  be 
encoded  and  returned  on  the  Data  Party  Line  Bus;  data  can  be  analog, 
discrete,  or  serial  magnitude,  each  type  consisting  of  eight  bits 
(discrete  data  is  scanned  in  groups  of  eight  sequential  channels) . 

The  format  of  these  32  bit  command  words  is  illustrated  in  Figure  3.  The 
front-end  sentry  of  each  RDM  detects  the  three  bit  sync  code  and  then  tests  the 
five  bit  address  field  of  each  command  sent  on  the  Command  Party  Line  Bus.  When 
the  address  field  matches  the  RDM  address,  the  remainder  of  the  command  word  is 
accumulated  while  switches  apply  power  to  the  decoder/mux  circuits  of  the  RDM 
for  the  subsequent  command  execution.  The  command  word  parity  bit  is  also 
checked  prior  to  command  execution.  If  not  addressed,  the  terminal  disconnects 
and  waits  for  the  next  sync  pattern.  The  addressed  terminal  regardless  of 
command  type  responds  with  a 13  bit  data  word  sent  on  the  Data  Party  Line  Bus 
for  return  to  the  TFG.  Each  data  word  consists  of  four  status  bits,  which 
indicate  the  quality  of  the  command  received  by  the  RDM,  and  an  odd  parity 
bit  for  the  first  12  bits  of  the  data  word.  When  executing  a telemetry  command, 
the  RDM  inserts  the  designated  eight  bit  data  word  into  the  response  word.  The 
telemetry  data  portion  of  the  TFG  tests  the  four  status  bits  and  the  parity 
bit  of  the  response  to  minimize  the  likelihood  of  an  undetected  error  in  party 
line  command/data  operation.  When  the  status  bits  indicate  an  error,  both  the 
AOP  computer  and  Ground  Station  are  flagged. 

3.1  PARTY  LINE  BUS  TIMING 

The  time  base  of  the  Command  Party  Line  Bus  is  divided  into  repetitive 
125  microsecond  periods  comprising  four  command  slots.  The  first  slot  of  the 
period  is  reserved  for  telemetry  commands  that  can  originate  from  either  the 
AOP  or  the  ROM  memory  of  the  TFG.  These  commands  establish  the  downlink  PCM 
telemetry  format.  Data-request  commands,  which  originate  only  frcm  the  AOP 
and  which  acquire  data  for  its  sole  use, are  sent  during  slots  two  and  four. 

These  commands  originate  from  two  sources,  real  time  commands  from  the  ground 
station  computer, via  the  CCD  time  delayed  and  control  algorithm  commands  from 
the  AOP.  Real  time  commands  are  allocated  slots  with  a 16MS  spacing  commen- 
surate with  the  maximum  uplink  command  rate  of  42  per  second.  The  time  slot 
division  of  the  Command  Party  Line  Bus  by  command  type  is  illustrated  by 
Figure  4. 
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Commands  pertaining  to  all  four  time  slots  originate  from  the  AOP.  The 
Special  1/0  (SIO)  for  the  AOP  consists  of  three  individual  buffers,  one  for 
each  of  time  slots  1 and  3 and  one  for  the  2-4  time  slot  pair.  These  buffers 
are  loaded  synchronously  with  their  respective  command  types  on  a direct  memory 
access  basis  from  previously  loaded  sections  of  memory.  The  buffer  commands 
are  then  unloaded  onto  the  Command  Party  Line  and  sent  to  the  RDMs  by  the 
designated  slot  enable  signals  generated  by  the  TFG. 

The  RDM  initiates  execution  of  the  command  at  the  beginning  of  the  next  slot. 
Serial  magnitude  and  telemetry  commands  are  completed  within  this  slot  period 
whereas  the  pulse  commands  continue  until  timed  out.  Serial  magnitude  commands 
comprised  of  16  bits  each  are  output  at  a 512  KBPS  rate.  Telemetry  data  are 
sampled  and  encoded  during  the  first  19  bit  periods  and  sent  on  the  Data  Party 
Line  during  the  last  13  bit  periods  of  the  slot.  The  operations  performed  by 
the  addressed  RDM  in  executing  the  three  command  types  are  indicated  by  the 
timing  diagrams  of  Figures  5 and  6. 

Since  pulse  commands  can  be  sent  to  the  same  RDM  from  two  independent 
sources  (AOP  and  CCD)  and  since  a common  pulse  width  source  within  each  RDM  is 
shared  by  ail  pulse  commands,  the  pulse  commands  to  an  RDM  must  be  spaced  in 
time  to  be  noninterfering.  The  time  slot  assignment  regulates  the  pulse  commands 
to  a 16  millisecond  spacing  for  each  command  source.  Accordingly,  logic  within 
the  SIO  interface  for  the  AOP  must  first  check  each  command  prior  to  its 
release  during  slots  two  and  four.  A more  sophisticated  solution  of  insuring 
non-interference  by  keeping  check  of  pulse  commands  sent  to  each  of  the  32  ROMs 
in  the  previous  six  millisecond  period  is  not  warranted. 

Accordingly,  the  RDM  may  be  commanded  to  sample  data  by  two  command 
sources  (TFG  and  AOP).  These  two  sources  are  inherently  non-iriterfering  for 
analog  and  bi- level  data,  and  also  for  serial  magnitude  data  if  only  one  eight- 
bit  serial  magnitude  data  word  is  assigned  to  each  input  mux  channel.  If  a 
mux  channel  services  multiple  data  words  by  end-to-end  of  stacking  of  shift 
registers,  then  ambiguous  read  out  could  result.  Under  these  circumstances 
it  is  necessary  to  prevent  the  interleaving  of  telemetry  commands  from  the 
TFG  and  data  request  commands  from  the  AOP  for  the  same  data  channel  of  the 
same  RDM.  This  problem  need  only  occur  when  the  number  of  mux  input  channels 
becomes  exhaused  and  doubling  up  is  required. 


This  problem  applies  to  serial  magnitude  commands  as  well.  If  command 
shift  registers  are  stacked  because  the  number  of  output  channels  are  exhausted, 
then  logic  must  be  contained  within  the  subsystem  to  generate  a multiple  command 
transfer  signal  that  stores  the  contents  of  the  shift  registers  into  buffer 
registers.  This  transfer  pulse  also  could  be  commanded  by  a pulse  command. 


IGURE  5.  RDM  SENTRY  OPERATIONS 


EST  PARITY  & TRANSFER 


Timing  information  must  also  be  routed  to  each  S/C  subsystem  via  the  party 
line  bus  umbilical.  The  1.024  MHz  bit  clock  and  the  32  KHz  word  clock  are 
derived  by  the  RDM  Sentry  from  the  Command  Party  Line  irrespective  of  command 
type.  However,  additional  timing  information  is  normally  required  in  order 
to  establish  the  beginning  of  computational  periods,  etc.  This  timing  infor- 
mation must  be  disseminated  to  all  subsystems  simultaneously.  Since  telemetry 
commands  are  sent  on  the  Command  Party  Line  periodically,  they  are  the  natural 
carrier  of  time  information.  However,  since  their  rate  is  a function  of  the 
PCM  bit  rate,  the  timing  information  is  not  absolute. 

Though  not  implemented  on  this  test  bed,  timing  information  derived  from  tie 
TFG  could  be  inserted  into  an  unused  field  to  convey  word,  minor  frame,  and 
major  frame  times.  Though  not  yielding  absolute  time  information,  these  times 
are  processed  to  perform  functions  that  are  dependent  on  telemetry  timing  such 
as  transfer  of  serial  magnitude  commands  and  data  into  buffer  registers  at 
designated  times.  To  accomplish  this  timing  function  the  RDM  Sentry  design 
must  be  altered  to  detect  not  only  a match  of  the  address  field,  but  also 
whether  the  command  is  a telemetry  command  irrespective  of  address. 

The  time  relationship  of  the  telemetry  commands  and  the  PCM  telemetry 
data  is  shown  in  Figure  7.  The  telemetry  PCM  bit  rate  is  commanded  to  one 
of  the  seven  binarily  related  rates,  64  KBPS  to  1 KBPS.  Selection  of  the 
PCM  bit  rate  also  establishes  the  corresponding  telemetry  command  rate  by 
enabling  only  those  number  one  time  slots  consistent  with  the  bit  rate. 

Though  the  Command  slot  period  remains  fixed  at  31.25  microseconds,  the 
frequency  at  which  telemetry  commands  are  released  is  slaved  to  the  selected 
PCM  bit  rate. 

3.2  PARTY  LINE  BUS  CHARACTERISTICS 


The  Command  and  Data  Party  Line  Buses  are  balanced,  shielded  twisted 
pair  cables  with  a characteristic  impedance  of  120  ohms.  This  bus  system 
links  the  C&DH  module  with  as  many  as  32  redundant  RDM  terminals.  Coupling 
to  the  bus  as  both  the  driver  and  receiver  ends  is  by  means  of  transformers, 
thus  isolating  each  RDM  from  each  other  and  the  C&DH  module.  This  isolation 
provides  better  control  over  ground  currents  and  system  noise.  The  RDM  is 
likewise  transformer  coupled  to  the  28  volt  power  bus  by  means  of  an  inverter 
power  supply  in  order  to  maintain  this  isolation. 


The  bit  rate  on  the  Command  Party  Line  is  fixed  at  1.024MHz.  Split  Phase 
Manchester  coding  was  selected  because  of  its  inherent  bit  sync  characteristic 
and  because  of  the  absence  of  a dc  spectral  comDonent.  The  transformer  bus 
coupling  requirement  dictates  that  the  dc  spectral  component  be  zero.  Bit 
synchronization  by  the  RDM  sentry  is  achieved  by  s local  asynchronous  oscillator 
that  operates  at  eight  times  the  command  bit  rate.  Two  clocks  are  derived 
from  a two  stage  counter  that  is  reset  with  each  code  transition.  One  clock 
samples  each  half  of  each  split  phase  bit  and  the  second  clock  transfers  the 
decoded  bit  into  the  command  shift  register.  During  the  worst  case  3 bit 


250 


sync  code  internal,  a two  bit  period  with  nc  transitions  precedes  and  follows 
the  single  transition  of  the  illegal  sync  pattern  "11-10-00".  During  these 
two  periods  the  accumulated  drift  of  the  clock  pulses  is  maximum  thus  limiting 
the  frequency  mismatch  tolerance  to  +5%.  This  tolerance  can  be  increased  by 
increasing  the  frequency  of  the  local  clock  oscillator  but  at  a sacrifice  of 
clock  pulse  width. 

Since  for  a typical  spacecraft  the  party  line  bus  cables  will  not  exceed 
100  feet,  the  out  and  back  transmisstion  delay  for  this  separation  is 
approximately  250  nanoseconds,  which  is  relatively  small  when  compared  with  the 
1000  nanosecond  bit  period.  Therefore,  because  the  common  sampling  window  of 
750  nanoseconds  easily  accommodates  data  frcm  RDMs  at  any  cable  separation 
distance  for  the  S/C,  the  coding  on  the  data  party  line  bus  need  not  contain 
clock  information.  Bi-polar  NRZ  coding  was  selected  because  the  absence  of 
a dc  component  satisfies  the  transformer  coupling  requirement  but  with  a 
3db  SNR  sacrifice. 

The  Command/Data  Party  Line  Bus  is  redundant  as  are  the  TFG  and  the  RDMs. 
Each  of  the  Command  Party  Lines  is  driven  by  either  of  the  redundant  TFGs, 
either  of  the  redundant  RDMs  for  a S/C  subsystem  is  activated  to  receive  and 
execute  the  command  sent  on  the  selected  line.  The  responding  RDM  of  the 
redundant  RDM  pair  is  selected  by  a pulse  command.  The  activated  RDM  responds 

on  one  of  two  data  party  lines  as  designated  by  the  select  bit  in  the  command. 

Bus  redundancy  is  illustrated  in  Figure  8. 

Each  of  the  line  driver  and  line  receiver  transformers  are  isolated  from 
the  buses  by  resistors,  thus  permitting  fault  tolerant  operations.  The 
resistors  soften  the  effect  of  a driver /receiver  malfunction,  which  other- 
wise would  render  the  bus  unusable.  Each  driver,  whether  in  the  TFG  or  RDM 
drives  as  many  as  32  transformers  thru  isolation  resistors.  The  driver  output 
signal  is  attenuated  by  approximately  75-80%  at  the  RDM  input  because  of  the 
fault  tolerant  resistor  isolation.  However,  the  attenuated  signal  is  recon- 
stituted by  a differential  receiver  with  a 1/2  volt  sensitivity. 

The  noise  rejection  property  of  the  Party  Line  Buses  is  80db  minimum, 

26  db  from  the  balanced  cable,  14  db  from  the  shielding  and  40  db  from  the 

input  transformer. 


4.  FUTURE  ENDEAVORS 


One  interesting  aspect  of  this  test  bed  planned  for  1977  is  the 
incorporation  of  more  intelligence  into  the  RDM  so  that  its  strict  slave 
personality  and  S/C  data  handling  can  be  improved.  The  objective  will  be  to 
reduce  non-functional  communications  over  the  Party  Line  Buses.  It  is 
estimated  that  only  1-5%  of  the  bus  communications  serves  a useful  function. 

If  the  RDM  had  the  capability  and  autonomy  to  edit  out  these  redundant  and 
meaningless  data  handling  operations  and  to  send  a status  summary  periodically 
and  alarms  as  detected,  a considerable  amount  of  bus  time  could  be  saved 
and  allotted  to  other  more  useful  functions.  Hopefully  hardware  savings  would 
also  be  realized.  However  a detailed  critical  design  analysis  must  first  relate 
the  S/C  functions  to  be  performed  to  hardware  alternatives. 
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THE  DEVELOPMENT  AND  EVALUATION  OF  A MUL  IPLEX 
DATA  BUS  SYSTEM  FOR  ADVANCED  RTV  APPLICATIONS 
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.ABSTRACT 


This  paper  will  shi  w how  the  implementation  of  MIL  STD  1 55TA  >n  t!.. 
ARFV  helps  t ignif  it  antly  In  improving  the  capabilit  y and  flexibility  of 
the  system.  Secondly,  it  will  describe  a hot  bench  mock-uf  that  will 
allow  testing  of  various  avionics  aspects  of  the  proposed  ARP\  to  reduc 
technical  and  cost  risks  associated  with  the  s-  stem.  This  hot  bench  ing 
has  been  made  feasible  and  cost-effective  with  tin  use  of  MIL-STD-1. 51  BA 
by  allowing  a large  portion  of  the  hot  bench  software  and  hardware  to  l>e 
reusable  in  other  system  hot  benches. 

INTRODUCTION 

RPVs  have  been  in  the  Air  H'orce  inventory  for  quite  some  time  .nd 
have  performed  many  valuable  services.  Wider  use  of  the  R1”  has  h.n 
slowed  bv  the  logistics  involved  in  launch,  flight,  and  re  ••.•,.rv  < ' the 
vehicle,  low  sortie  rate,  insufficient  survivability  in  a nigh  threat 
area,  and  a data  link  usable  in  a dense  electronic  warfare  situation. 

MISSION  REQUIREMENTS 

The  baseline  for  the  proposed  ARPV  is  operation  in  the  European 
theater  in  the  1980's  to  supplement  and  reduce  attrition  of  manned  aii 
craft  against  a numerically  larger  force  until  additi.  iril  weapons  i on  ' 
brought  to  bear  on  the  aggressor,  assuming  a nonnuclear  conflict.  The 
types  of  missions  this  entails  include:  photo  and  near  real  time  recon- 

nai  sanee  (both  pie  and  post  strike),  strikes  against  area  targets,  and 
elect  ron i c count erme as u i: es 
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SYSTEM  IMPLICATIONS 


These  mission  requirements  necessitate  that  the  ARPVs  have  the  capa- 
bility for  night/all-weather  ground  launch  and  recovery  to  sustain  the  high 
sortie  rates  required  in  the  initial  stages  of  the  conflict  so  as  to  relieve 
the  manned  aircraft  for  other  duties.  The  high  electronic  countermeasures 
threat  environment  necessitates  that  at  least  for  most  of  the  mission,  the 
ARPV  will  have  to  be  autonomous  in  operation,  and  what  control  is  given  by 
the  operator  will  be  of  a higher  order  nature  (i.e.  land,  change  target, 
or  turn  to  heading  of  140).  To  insure  a high  mission  success,  several  APPVs 
will  be  sent  on  most  missions.  This  implies  the  ability  to  fly  station- 
keeping in  formation.  The  necessary  relative  position  fixes  can  be  obtained 
through  the  Joint  Tactical  Identification  System  (JTIDS)  as  presently  pro- 
posed. The  hostile  electronic  environment  that  will  be  encountered  and  high 
degree  of  self-contained  navigational  capability  required  dictate  the  use  of 
an  inertial  navigation  system  (INS)  for  real  time  navigation.  Terrain  Con- 
tour Matching  (TERCOM)  will  be  used  to  provide  a position  fix  update  for 
the  INS.  TERCOM  uses  measurements  of  altitude  from  a radar  altimeter  to 
determine  a given  ground  profile  which  is  in  turn  matched  against  a pre- 
stored profile  to  obtain  a fix. 

The  landings  will  be  automated  to  reduce  attrition  due  to  operator 
error  and  help  reduce  congestion  which  occurs  as  a formation  of  ARPVs 
returns  from  a mission  by  increasing  the  recovery  rate.  The  Microwave 
Landing  System  (MLS)  and  the  radar  altimeter  will  be  used  in  conjunction 
to  give  the  necessary  information  required  for  landings. 

A high  sortie  rate  requires  that  the  minimal  amount  of  support  equip- 
ment will  be  required  in  between  sorties.  With  ground  power  connected,  a 
maintenance  panel,  which  is  an  integral  part  of  the  ARPV,  can  be  used  to 
check  vehicle  go/no-go  status.  The  built-in  test  (BIT)  capabilities  of 
the  avionic  subsystems  will  be  used  to  identify  the  faulty  equipment  through 
the  maintenance  panel.  For  some  subsystems,  external  support  equipment  will 
be  required  to  adequately  diagnose  faults  (i.e.  air  data  or  radar  altimeter). 
Pertinent  information  relating  to  system  health  will  be  stored  on  a magnetic 
tape  cassette  for  post-flight  support  equipment  analysis. 

The  same  cassette  will  be  used  to  enter  mission  program  data  and  TERCOM 
data  into  the  ARPV  and  to  store  mission  results  for  later  ground  analysis. 

Taking  these  basic  requirements  into  context  with  life  cycle  cost, 
mission  effectiveness,  and  RPV  lifetime  as  specified  in  terms  of  number  of 
missions,  an  ARPV  avionics  suite  as  shown  in  Figure  1 was  proposed. 

A MIL-STD-1553A  multiplex  data  bus  (MUX)  is  used  as  the  desired  inte- 
gration approach.  Unlike  in  a manned  aircraft  where  avionics,  stores 
management,  and  flight  controls  would  most  likely  be  on  separate  mux  buses, 
a single  nonredundant  mux  bus  is  used  since  pilot  safety  is  not  an  issue. 

This  does  not  mean  there  is  no  redundancy  built  into  the  system.  The  flight 


FIGURE  1.  ARPV  AVIONICS  SUITE 


controls  irm.tssor  can  be  used  as  back-up  bus  controller  and  also  contain 
unsophisticated  navigation  software  to  provide  a "get  home"  capability. 

There  is  sufficient  redundancy  of  navigational  information  obtained  from 
the  Lor an  receiver,  JT1DS  terminal,  radar  altimeter,  air  data  sensors,  and 
INS  to  allow  failures  to  occur  without  loss  of  the  ARPV.  A third  level  of 
redundancy  can  be  obtained  by  relaying  control  and  navigational  information 
between  AI’PVs  flying  in  formation  through  the  JTIDS  terminals. 

As  shown  on  Figure  1,  not  all  devices  are  connected  to  the  mux  bus. 

The  criteria  for  requiring  interface  to  the  mux  bus  includes  physical 
location  of  equipment,  probability  of  updating  this  equipment,  and  quantity 
of  data  flow  into  and  out  of  the  equipment.  Using  this  criteria,  the  sur- 
face actuators,  fuel  system,  and  engine  controls  were  hardwired  to  the 
flight  control  computer.  The  Microwave  Landing  System  (MLS)  receiver, 
radar  altimeter,  air  data  sensors,  and  IFF/SIF  have  a moderate  flow  of 
information  but  have  a low  probability  of  being  updated  during  the  APfPV 
lifetime.  A general  RT  is  used  to  reduce  cost  without  significantly  de- 
tracting from  ARPV  flexibility. 

A brief  discussion  of  major  avionic  elements  follows. 

INKRTTAL  NAVIGATION  SYSTEM 

To  reduce  initial  and  life  cycle  costs,  the  INS  is  assumed  to  be  the 
F— 16  INS  (as  is  the  USAF  standard  INS).  It  is  supplied  with  a MIL-STD-1553A 
interface  and  has  the  capability  to  act  as  the  back-up  bus  controller. 

Based  on  present  Information,  it  does  not  appear  cost-effective  to  use  the 
back ■■up  bus  controller  feature.  This  is  due  to  the  significant  changes  in 
the  software  which  are  required  to  implement  this  feature  and  the  subsequent 
expensive  validation  and  verification  of  the  entire  INS. 

FLIGHT  CONTROLS  PROCESSOR 

The  flight  controls  processor  performs  the  high  speed  inner  loop  calcu- 
lations for  flight  control  stability,  interface  to  and  operation  of  control 
surfaces,  engine  control,  and  fuel  quantity.  Unsophisticated  navigation  and 
back-up  bus  control  could  also  be  implemented.  In  addition,  the  processor 
..ill  periodically  perform  self-checks  on  itself  and  its  interface  hardware 
and  report  status  to  the  mission  computer  for  system  BIT  activity.  A micro- 
processor with  a 16-bit  parallel  architecture,  interrupt  capability,  and  an 
add  time  of  less  than  8.0  microseconds  would  he  sufficient  for  this  applica- 
tion. This  is  typified  by  the  National  Semiconductor  IMP-16  microprocessor. 

I .ORAM  MICROPROCESSOR 

The  LORAH  receiver  is  interfaced  to  the  mux  bus  through  an  RT  containing 
j microprocessor  which  controls  the  LORAN  receiver  and  converts  the  receiver 
time  difference  outputs  to  latitrtie/longitude  position  fix.  Preliminary 


review  of  the  processing  requirements  indicates  that  an  IMP-] 6 class  micro- 
processor will  also  be  suitable  for  this  task. 

JTIDS  RECEIVER 

Due  to  the  high  input/output  requirements,  the  JTIDS  receiver  is  inter 
faced  to  the  mux  bus.  Current  information  indicates  that  an  embedded  pro- 
cessor in  the  low  cost  JTIDS  receiver  will  only  provide  an  output  which 
consists  of  a message  time-of-arrival  (TOA)  and  the  JTIDS  message  itself 
Modification  of  the  embedded  JTIDS  processor's  software  to  perform  the 
position  fix  requirements  is  not  suitable.  This  would  create  an  ARPV 
peculiar  JTIDS  terminal  which  would  defeat  the  intent  of  hardware  commonality 
with  manned  aircraft  and  its  associated  cost  benefits.  A viable  alternative 
is  to  use  an  RT/ microprocess or  combination.  The  microprocessor  would  act  as 
the  first  level  filter  and  buffer  for  the  JTIDS  messages.  Thus,  only  messages 
of  specific  interest  to  the  vehicle  and  those  TOAs  and  associated  position 
fixes  of  equal  or  better  quality  than  the  current  vehicle  calculated  position 
would  be  passed  on  to  the  mission  computer.  The  mission  computer  would  per 
form  the  actual  position  fix  calculations.  The  processing  requirements  are 
much  less  stringent  than  for  the  flight  control  processor,  but  an  identical 
processor  should  be  used  to  reduce  logistics  costs. 

STATION  LOGIC  UNITS 

The  Station  Logic  Units  (SLUs)  are  RTs  which  interface  to  a variety  of 
ARPV  payloads  which  do  not  have  a mux  bus  interface  built  into  the  store. 

The  SLUs  are  located  in  close  proximity  to  the  hard  points  on  the  airframe 
for  the  stores.  A terminated  bus  stub  is  provided  to  directly  connect  the 
more  sophisticated  payloads  that  have  embedded  RTs.  The  ARPV  is  anticipated 
to  use  five  SLUs. 

MISSION  COMPUTER 

Through  the  mux  bus,  the  mission  computer  will  act  as  the  integration 
focal  point  for  the  vehicle.  This  will  allow  the  system  to  be  reconfigured 
to  match  the  various  missions,  different  degraded  modes  of  operation,  and 
to  meet  new  operational  requirements.  A worst  case  study  of  the  information 
Plow  was  conducted  assuming  the  maximum  JTIDS  data  rate  which  occurs  when 
configured  with  the  RECCE  payload.  It  was  found  that  the  duty  cycle  in  this 
situation  was  only  16.8%  of  the  total  bus  capacity.  Thus  there  will  he  more 
than  83%  reserve  capacity  for  future  growth.  The  mere  fact  that  there  is 
reserve  mux  bus  capacity  does  not  totally  insure  adequate  growth  potential. 

If  the  bus  I/O  hardware  section  of  the  mission  computer  is  of  a simplistic 
design,  then  much  of  the  detailed  control  must  be  implemented  in  software. 

Thus  only  30%  to  50%  of  the  actual  bus  capacity  may  in  fact  be  truly  avail- 
able. In  order  to  use  more  of  the  bus  capacity,  a moderately  complex  bus 
controller  I/O  must  be  employed  to  reduce  software  loading. 

Included  in  the  bus  controller  functions  are  all  the  signal  transmission 
fault  recovery  operations. 
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The  mission  computer  (MC)  will  use  inputs  from  the  LORAN  receiver, 
inertial  navigation  system  (INS),  air  data  sensors,  radar  altimeter,  flight 
controls  processor,  and  JTIDS  and  TERCOM  position  fixes  to  determine  present 
position  through  suitable  digital  filtering  techniques.  The  MC  must  process 
stored  waypoints  and  PME  operation  instructions,  determine  suitable  flight 
path  modifications  based  on  current  position,  and  activate  PME  as  required. 
Based  on  current  position,  mission  program,  and  flight  sensors,  the  MC  must 
issue  specific  commands  to  the  flight  controls  processor  to  direct  the  flight 
of  the  vehicle.  Also  included  in  guidance  is  the  need  to  accept  manual 
flight  control  via  JTIDS  and  initiation  of  specific  maneuvers  for  weapon 
and  implant  delivery.  The  MC  will  be  responsible  for  performing  system 
built-in  test  (BIT)  on  a preflight,  in-flight,  and  post-flight  basis. 

Based  on  these  requirements,  the  following  general  capabilities  are 
needed  by  the  ARPV  mission  computer. 

(a)  Instruction  Set  (Core  Memory) 

ADD  (fixed  pt.,  single) 

ADD  (fixed  pt. , double) 

ADD  (floating  pt.) 

MULTIPLY  (fixed  pt. , single) 

MULTIPLY  (floating  pt.) 

(b)  Structure 

General  Register  (16  minimum) 

16K  Core  Memory  (32K  expansion) 

MIL-STD-1553A  Bus  Control  I/O 
External  Interrupts  (8  minimum) 

DISTRIBUTED  PROCESSING 

The  use  of  microprocessors  to  "distribute"  the  computational  power 
throughout  the  ARPV  reduces  the  throughput  required  of  the  mission  computer 
and  increases  the  modularity  of  the  system.  As  microprocessor  and  sensor 
technology  increases,  a corresponding  decrease  in  mission  computer  load 
will  occur,  thus  making  software  maintenance  easier  since  the  MC  total 
software  program  has  shrunk  as  the  processing  power  becomes  more  distributed. 
This  is,  of  course,  based  on  the  assumption  that  the  computational  power 
requirements  will  stay  relatively  constant. 

SYSTEM  ENGINEERING  AND  ANALYSIS 

In  the  preceding  section,  an  overall  avionics  systems  approach  was 
identified  and  a baseline  avionics  suite  defined  for  the  ARPV.  It  now  re- 
mains to  define  a suitable  engineering  hot  bench  approach  to  address  detailed 
questions  of  engineering  feasibility,  cost  savings,  and  technical  and  cost 
risk. 


4.0  microseconds 

8.0  microseconds 

10.0  microseconds 
8.0  microseconds 

30.0  microseconds 
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Precursor  efforts  in  the  ASD/ENA  Systems  Engineering  Avionics  Facility 
(SEAFAC)  have  resulted  in  a first  phase,  or  mini  hot  bench,  as  shown  in 
Figure  2.  This  hot  bench  was  intended  to  provide  initial  insight  into  the 
ARPV  integration  problem  and  establish  the  basis  for  a more  complete  avionics 
hot  bench.  The  mini  hot  bench  is  integrated  through  a MIL-STD-1553  multiplex 
data  bus  with  the  bus  controller  and  prime  processing  duties  residing  within 
a general  purpose  avionic  computer  (a  General  Electric  model  CP-16).  The 
air  vehicle,  its  power  subsystems,  and  its  navigation  sensors  are  simulated 
by  another  avionics  computer  (a  Westinghouse  AN/AYK-8  which  is  "flown"  by 
the  CP-16).  Two  representative  ARPV  payloads  are  included  within  the  mini 
hot  bench.  These  are  namely  the  KS-120  panoramic  film  camera  and  the  AXQ-2 
television  camera/display  subsystem,  also  shown  in  Figure  2.  Also,  an  ARPV 
remote  operator  station  is  provided  through  the  use  of  a terminal  on  the 
mux  bus  which  interfaces  to  a graphics  CRT,  alphanumeric  display /keyboard , 
and  a force  stick  hand  control.  This  operator  interface  is  intended  only 
to  provide  a definition  of  information  flow  and  impact  on  software  design 
and  does  not  address  any  human  factors  questions. 

To  date  the  results  of  the  mini  hot  bench  have  been  many.  In  the  hard- 
ware area,  a standard  multiplex  terminal  unit  (MTU)  design  was  developed 
in-house.  This  converts  the  biphase  Manchester  signal  off  the  mux  bus  into 
parallel  NRZ  digital  data  with  associated  control  lines.  To  interface  a 
subsystem  (i.e.  KS-120  or  magnetic  tape  cassette)  to  the  mux  bus,  all  that 
is  required  is  the  peculiar  I/O  module  to  interface  to  the  NRZ  interface. 

Thus  a proven  design  can  be  used  over  and  over.  This  procedure  can  be 
directly  applied  to  the  ARPV. 

The  key  word  in  the  ARPV  design  is  modularity,  and  it  is  no  less  impor- 
tant in  the  software.  A highly  flexible  multiprogramming  executive  was 
designed  and  implemented  to  permit  the  operation  of  multiple  independent 
software  modules  to  be  configured  as  both  stand-along  and  integrated  modules 
within  the  same  computer.  This  allowed  the  functional  software  modules  to  be 
configured  as  both  stand-alone  and  integrated  programs  for  ease  of  debugging. 
The  mux  bus  I/O  was  designed  as  a table  driven  operation  so  that  changes  in 
bus  traffic  flow  could  be  effected  by  merely  changing  table  entries.  Soft- 
ware interface  and  configuration  control  procedures  were  implemented  with 
the  goal  of  maintaining  the  integrity  of  the  modularity. 

To  build  and  debug  the  mini  hot  bench,  tools  had  to  be  developed  to  be 
used  in  integration  and  checkout.  A manual  bus  tester  was  developed  to 
allow  both  monitoring  of  the  mux  bus  traffic  and  excite  the  individual  remote 
terminals  (RT)  for  initial  checkout  without  interaction  with  untested  software. 
To  handle  the  problems  associated  with  debugging  a real  time  system,  a program 
called  SEDPAC  was  developed.  This  allows  the  software  engineers  to  view  and 
modify  internal  parameters  and  programs  while  the  hot  bench  is  in  operation. 
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FIGURE  2.  aRPV  MINI  HOT  BENCH 


ARPV  MAJOR  HOT  BENCH 


r 


The  final  configuration  for  the  ARPV  major  hot  bench  is  based  on  the 
results  of  the  three  ARPV  study  contracts,  the  ENA  in-house  analysis,  and 
the  mini  hot  bench.  The  major  hot  bench,  as  shown  in  Figure  3,  will  incor- 
porate the  avionic  elements  of  the  mini  hot  bench.  A PDP-11/55  minicomputer 
will  replace  the  AYK-8  simulator,  allowing  greater  flexibility  and  utility. 
The  PDP-11/55  will  act  as  a real  time  simulator  and  monitor.  The  simulation 
activity  will  center  around  the  ARPV  air  vehicle  flight  characteristics , 
flight  controls,  engine,  fuel  system,  inertial  navigator,  and  RF  portion 
of  the  data  link.  It  will  also  act  as  a real  time  stimulator  for  hot  bench 
sensors,  providing  inputs  to  the  sensors  as  if  they  were  actually  flying. 

The  monitor  function  will  consist  of  the  hardware  and  software  necessary  to 
extract  information  from  the  data  bus  so  as  to  provide  the  engineers  with  a 
real  time  view  into  the  hot  bench  operation. 

At  present  work  is  continuing  on  the  maxi  hot  bench  with  the  design  and 
development  of  a new  bus  controller  for  the  CP-16  to  reduce  software  over- 
head and  increase  I/O  throughput  capability.  Interfaces  are  presently  being 
designed  and  developed  for  the  Loran  receiver,  SUU-25  dispenser,  ALE-38  pod, 
IFF,  mass  storage  device,  and  maintenance  panel. 

SUMMARY 

The  end  result  of  this  major  hot  bench  effort  will  be  to  give  the  RPV 
System  Program  Office  (SPO)  sufficient  information  to  identify  the  risks 
and  needs  of  the  avionics  portion  of  the  ARPV.  In  addition,  the  SPO  will 
be  provided  with  a detailed  set  of  hardware  and  software  specifications 
which  will  permit  the  SPO  to  initiate  procurement  of  the  prototype  ARPV 
avionics. 
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MULTIPLEXED  DIGITAL  DATA  BUS 
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Abstract 

The  use  of  the  airborne  on-board  processor  to  operate  in  a uniquely- 
controlled  mode  for  self-validation  and  the  subsequent  validation  of  the  sub- 
systems that  are  connected  to  the  digital  data  bus  are  examined, 

A description  of  a data  bus  access  for  rapid  prelaunch  checkout  validation 
of  a Remotely  Piloted  Vehicle  (IIPV)  is  presented.  MIL-STD-1553  multiplex 
standard  is  supported  for  RPV  applications.  This  concept  can  eliminate  the 
many  measurement  instruments  traditionally  used  for  this  purpose.  The  digi- 
tal state  of  the  addressed  subsystem  is  used  as  an  indicator  for  the  operator 
to  assess  the  status  of  the  RPV. 

This  organizational  maintenance-level  checkout  concept  utilizes  die  on- 
board vehicle  processor  instruction  and  priority  schemes  to  individually 
address  each  RPV  subsystem  and  conduct  evaluations.  Tests  can  be  selec- 
tively structured  to  permit  varying  levels  of  test  complexity,  prelaunch  read- 
iness, line  replaceable  unit  (weapon  replaceable  assembly)  fault  identification, 
and  with  suitable  ancillary  equipments,  de+ailed  bench  level  testing. 

The  data  bus  concept  permits  full  system  evaluation  without  the  need  for 
many  special  test  connector  interfaces  with  the  interface  unit  and  end  items 
typical  of  the  present  computer  test  systems. 
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Future  RPV  avionics  support  equipment  must  provide  rapid,  simple,  accurate  ad  cost 
effective,  prelaunch  and  organizational  level  checkout  capability. 


What  are  the  basic  problems  in  RPV  avionics  support?  As  interpreted  i.i 
this  paper,  the  main  issues  are: 

• Availability  of  the  RPV  to  perform  the  intended  mission. 

• Reliability  levels  that  insure  successful  completion  of  the  mission. 

• Maintainability  of  the  vehicle  design  to  provide  for  equipment 
accessibility. 

• Testability  such  that  the  vehicle  can  easily  be  connected  to  a test 
system  and  be  accurately  evaluated. 

Collectively,  the  avionics  support  engineer  must  face  and  solve  these 
problems  if  he  is  to  determine  how  to  best  support  the  modern  RPV  avionics 
suite  for  rapid  turnaround . 

As  a matter  of  background  information,  TRA  has  built  a series  of  RPV 
electrical /avionics  system  (AGE)  test  consoles  (in  addition  to  other  mechani- 
cal and  bench  level  equipments)  for  use  by  the  various  military  agencies; each 
with  specific  individual  performance  requirements  for  their  respective  pro- 
grams. Quite  naturally,  these  test  consoles  exhibit  certain  similarities,  as 
they  were  all  designed  under  similar  basic  criteria.  All  are  simple  in  opera- 
tional concept,  are  easy  to  use,  offer  flexibility  to  change  to  other  vehicles, 
are  programmable  for  other  applications  and  use  low  cost  conventional  indus- 
trial quality  measurement  instruments.  To  a large  extent,  these  tests  are 
performed  manually  by  the  maintenance  operator  with  the  aid  of  published 
handbooks . 

These  basic  designs  were  conceived  and  built  over  15  years  ago  and  have 
been  in  continual  use  since.  They  have  been  modified,  added-onto,  extended, 
supplemented,  crutched,  and  tailored  to  adapt  to  a continual  evolution  of  new 
avionics  installations.  They  have  enjoyed  an  enviable  satisfactory  history  of 
availability  and  reliability.  This  is  not  to  suggest  that  this  series  of  designs 
were  optimum  nor  a panacea  for  all  similar  applications,  rather  to  prove  that 
functional  interchangeability  and  flexibility  for  growth  is  a possible  and  practi- 
cal concept. 
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Paradoxically  then,  if  this  evolutionary  process  is  valid,  why  not  continue 
with  this  type  of  AGE  electrical  design  ? Why  has  there  been,  always  in  the 
background,  a desire  to  change  this  approach  to  AGE  support  equipment?  One 
answer  of  course,  is  a need  to  improve  the  avionics  checkout  time;  primarily 
to  reduce  the  turnaround  queue,  to  get  more  RPVs  into  the  air,  and  improve 
the  sortie  rate.  Another,  and  the  main  issue,  is  that  avionics  systems  are 
rapidly  changing.  Technology  is  maturing.  Today's  laboratory  micro-power, 
macro-speed,  curiosities  are  tomorrow's  hardware.  Avionics  packages  are 
no  longer  simple  brute  force  power  relay  systems;  they  contain  sophisticated 
circuits  and  require  special  handling  in  both  signal  levels  and  in  the  prime 
power  source.  In  effect,  they  are  computer  compatible  systems  and  as  such 
can  more  easily  interface  to  computers.  TTL,  CMOS,  and  low  power  discrete 
circuits  are  now  used  more  often  than  in  the  past.  Collectively,  these  criteria 
demand  a sophisticated  avionics  AGE  support  system. 

Obviously,  the  high-speed  digital  computer  is  a candidate  method.  Com- 
puters for  critical  airborne  applications  are  not  new,  but  the  single  require- 
ment of  MIL-T-21200,  has  long  prevented  wide  spread  computer  applications 
for  ground-based  vehicle  and  RPV  checkout  systems.  Commercial  airline 
operations  were  the  first  to  use  large  computers  for  avionics  support  as  they 
enjoy  the  luxury  of  controlled  environments.  Military  applications  have  fol- 
lowed in  selected  installations  wherein  the  environment  could  be  economically 
controlled  or  ignored. 

Computer-aided  testing  has  been  the  traditional  recommendation  for  major 
military  programs.  Typically,  they  include  ? ground-based  processor  with  a 
circus-wagon  train  of  peripheral  equipments  and  interconnecting  cables.  The 
connect  and  disconnect  time  of  all  cables  employed  critically  reduce  the  avail- 
able time  for  tests.  Conventionally,  the  central  processor  is  connected  to  a 
universal  interface  unit.  This  provides  a common  junction  point  for  all  the 
vehicle  subsystems  to  access  the  computer  during  free-flight  operations.  For 
evaluation  testing,  only  the  circuits  that  are  brought  forward  from  the  end 
item  to  the  interface  unit  can  be  tested  or  measured  unless  additional  cables 
together  with  buffered  access  ports  at  the  end  item  under  test  are  furnished. 

A typical  RPV  spends  over  70  percent  of  its  useful  life  in  the  hangar 
awaiting  repair,  or  in  the  repair  cycle,  or  awaiting  validation  after  repair. 

In  many  instances,  system  elements  requiring  mechanical  repair  (like  engines, 
fuel  control,  or  aerodynamic  surfaces)  create  the  delays  but  the  avionics  com- 
plement of  the  modem  tactical  RPV  air  vehicle  is  far  from  simple  and 
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statistically  has  been  the  major  reason  for  a red  X'd  status.  Parts  count 
alone  numerically  reduces  the  overall  reliability. 

Rapid  system  and  subsystem  analysis  of  suspect  systems  is  a mandatory 
vehicle  turnaround  requirement  to  permit  high  availability  of  RPV  for  high 
sortie  mission  assignments. 

Any  major  system  includes  a complement  of  associate  or  subcontractor 
developed  mission  equipments.  RPV  programs  are  no  exception.  Naturally, 
associate  contractors  develop  a complete  line  of  support/maintenance,  equip- 
ments, both  organizational  and  field  level,  for  their  particular  systems. 
Company  accountants  rationalize  that  the  development  of  these  support  equip- 
ments are  paid  for  by  other  or  previous  programs  and  that  they  may  be  in- 
cluded into  the  air  vehicle  systems  at  minimum  cost.  The  program  manager 
is  then  compromised  into  accepting  a circus  train  of  extra  equipment  with 
varying  AGE  design  methodology  precluding  any  hope  for  efficient  integration. 

However,  as  experience  has  shown  when  this  is  done  the  system  life  cycle 
cost  rises  very  rapidly  because  of  the  widely  divergent  methodology,  test  pro- 
cedures and  equipment  that  is  furnished;  equipment  like  signal  sources,  exci- 
tation power  supplies  and  a host  of  measurement  devices.  Preparation  of 
calibration  summary  reports  and  periodic  maintenance  for  these  duplicate 
equipments  can  easily  absorb  m any  additional  thousands  of  program  dollars, 
not  to  mention  the  unnecessary  test  equipment  located  in-situ. 

Historically,  the  organizational  maintenance  concepts  and  procedures  fol- 
low trends  used  during  the  engineering  development.  Accordingly,  a great 
many  development  test-oriented  and  would-be-nice-to-kr.ow  tests  and  measure- 
ments are  included  in  the  test  repertoire.  Usually,  the  test  sequences  are 
established  using  low-cost,  easily-modified  manual  equipments  and  handwritten 
procedures  which  are  economically  difficult  to  change  for  the  operational  test 
system.  With  typical  hardware  and  software  interfaces  that  are  employed  in 
modern  computer-aided  central  test  system,  it  is  equally  difficult  to  modern- 
ize or  simplify  development  engineering  tests,  and  as  a result,  the  organiza- 
tional level  tests  very  often  remain  similar  to  tests  used  during  the  develop- 
mental phases. 

To  insure  a high  level  of  confidence  that  the  RPV  is  operationally  ready 
for  flight  prior  to  loading  of  mission  stores,  a functional  check  of  avionics  and 
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electrical  subsystems  must  be  conducted.  This  check  is  analogous  to  the 
power-on  preflight  check  conducted  by  a pilot  prior  to  take  off  of  a manned 
aircraft.  The  check  is  a qualitative  check  of  critical  and  low  MTBF  subsys- 
tems to  verify  operational  serviceability  and  provides  go/no-go  decision  on 
RPV  flight  readiness.  To  minimize  prelaunch  preparation  time,  the  check 
must  be  limited  to  as  few  tests  as  are  necessary  to  verify  equipment  service- 
ability at  the  subsystem  level  without  making  precise  quantitative  measure- 
ments of  operational  limits,  such  as  linearity,  voltage  levels,  frequency, 
time  of  travel,  etc. 


Future  vehicle  avionics  systems  will  employ  the  multiplexed  digital  data  bus  concept 
for  cost  and  weight  savings,  simplicity  of  installation,  noise  immunity,  test  simplification 
and  flexibility. 

To  implement  an  efficient  system  level  test  concept,  an  integrated  AGE/ 
airborne  design  approach  is  necessary.  This  new  AGE/support  system  design 
concept  assumes  the  air  vehicle  will  have  a proliferation  of  sophisticated 
equipments,  and,  most  importantly,  the  multiplexed  digital  data  bus  inter- 
connecting network.  The  vehicle  avionics  system,  then  has  several  salient 
features,  viz: 

• Multiplexed  Data  Bus  in  Conformance  with  MIL-STD-1553: 

- Multiplex  Terminal  Units  (MTUs) 

- Subsystem  Interface  Units  (SSIUs) 

- Processor  I/O  Bus  Access  Port  for  Organizational  Level 
Validation 

• High  Reliability  Digital  Processor 

• Navigation  Equipments 

• Sensor  Equipments 

• Autoflight  and  Stabilization  Equipments 

• Engine  and  Fuel  Control  Equipments 

• Payload  Devices 
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A hypothetical  vehicle  containing  compartmented  enclosures  typical  of 
many  conventional  aircraft  and  RPVs  is  diagrammed  in  Figure  1.  The  multi- 
plexed digital  data  bus  functions  are  described  in  detail  and  performance 
requirements  specified  in  MIL-STD-1553. 


Figure  1.  Air  Vehicle  Avionics  Installations  Typically  are  Located 
in  Compartmented  Areas.  The  Multiplexed  Digital  Data 
Bus -Intercommunications  Permit  Simplified  Installation 
as  Well  as  End  Item  Test  Access. 

This  standard  calls  for  a 1 megabit  data  rate  and  for  special  timing  and 
word  formats.  Brief  descriptions  as  applied  hereto  are  discussed  later  in 
this  paper.  The  multiplexed  digital  data  bus  is  routed  through  all  compart- 
ments to  several  multiplex  terminal  units  (MTUs). 

The  multiplex  digital  data  bus  as  specified  in  MIL-STD-1553,  is  a twisted, 
shielded  pair,  continuous  loop,  running  throughout  the  vehicle  to  convenient 
terminal  junctions;  aft,  dorsal,  ventral,  and  forward  equipment  compartments, 
and  the  engine  compartment1 . 


1 The  twisted  pair  digital  cable  will  probably  be  replaced  by  a rapidly  matur- 
ing technology-fiber  optics  cable,  which  offers  significant  benefits  in 
shielding,  cross-talk  and  noise  immimity  compared  to  the  twisted  wire 
cable  currently  in  use. 
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Only  one  MTU  is  located  in  each  compartment;  the  data  bus  is  used  to 
interconnect  the  MTUs.  The  bus  controller  is  colocated  with  the  processor 
and  is  used  as  the  data  bus  control  center.  In  each  compartment,  the  several 
vehicle  avionics  functions,  or  end  items,  are  connected  to  the  MTU  through 
the  subsystem  interface  unit  (SSIU).  Therefore,  all  end  items  are  connected 
to  the  processor  much  like  a computer  time  share  installation.  One  of  the 
MTUs  is  employed  as  the  umbilical  interface  and  thereby  can  act  as  an  "end 
item".  This  will  permit  full  vehicle  monitor  and  control  through  the  data  bus. 
Communication  to  the  prelaunch  control  center  is  also  through  the  data  bus. 

In  addition,  the  processor  I/O  bus  is  ported  to  a vehicle  access  door  to  permit 
connection  to  an  organizational  level  AGE  test  set  to  be  herein  described  later. 

The  multiplexed  digital  data  bus  provides  simple,  easy  access  to  the 
vehicle  subsystem  intercommunication  network  and  thereby  can  assess  all  end 
items  from  one  point.  This  minimizes  the  usual  large  number  of  test  cables 
that  are  required  for  other  test  concepts.  Additionally,  the  airborne  vehicle 
processor  is  used  as  the  test  computer,  after  self-validation,  eliminating  the 
expensive  ground-based  computer. 

Change  is  a way  of  life  to  the  military  avionics  installation  community.  In 
many  cases,  the  vehicle  avionics  configuration  is  changed  several  times  before 
development  flight  tests  are  completed.  The  multiplexed  digital  data  bus  per- 
mits easily  configured  vehicle  changes  without  the  necessity  for  major  wiring 
and  harness  modifications. 

An  additional  serious  concern  of  the  military  is  early  obsolescence  of  any 
newly  procured  prime  mission  equipment  and  navigation  aids,  including  their 
test  or  support  equipments.  This  is  especially  true  when  the  services  have 
spent  many  hard-fought-for  dollars  and  time  on  program  authorizations.  The 
multiplexed  digital  data  bus  concept  insures  that  any  subsequent  avionics  sys- 
tem designed  in  future  years  can  be  economically  integrated  into  a vehicle. 

The  multiplexed  digital  data  bus  and  promised  standardization  of  the 
associated  remote  terminals  used  therewith  will  provide  capability  for  a truly 
integrated  AGE  equipment.  Associate  contractors  airborne  equipment  by 
design  intent,  must  be  compatible  with  the  remote  terminal  and  accordingly, 
can  be  easily  integrated  with  the  methodology  employed  in  the  multiplex  termi- 
nal units  and  the  common  support  equipment. 
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A typical  remote  terminal  structure  is  shown  in  Figure  2.  It  identifies 
registers  that  are  used  in  the  conduct  of  information  across  the  interface 
between  the  computer  and  end  item. 

The  remote  terminal  for  each  subsystem  contains  address  decoding  and 
channel  selection  registers  in  addition  to  the  system  control  logic.  The  sub- 
system interface  contains  signal  conditioning,  sample  and  hold  registers,  D/A 
conversion  and  signal  sampling,  all  under  a subaddress  control. 
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Figure  2.  Functional  Task  Assignments  for  the  Digital 
Data  Bus  Remote  Terminal.  The  Multiplex 
Terminal  Unit  and  Subsystem  Interface  Unit 
Complies  With  Proposed  MIL-STD-1553 
Standardization  Intent. 

During  the  vehicle  avionics  equipment  end  item  test  design,  the  MTU/SSIU 
registers  are  addressed  for  each  item  under  test;  input  and  output  states  as- 
signed, values  selected,  sequential  analog  measurements  made,  in  addition  to 
logic  state  indications  for  the  system  under  test. 

Normally,  test  design  is  based  upon  individual  consideration  of  the  test 
requirement  documents  furnished  by  each  subsystem  and  end  item  designer. 
The  capability  for  a full  automatic  testing  is  provided  in  the  SSIU  with  but 
minor  limitations  of  the  pinout  assignments  for  one  test  period.  The  collec- 
tion of  registers  and  conversions  devices  can  all  be  individually  addressed  for 
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a particular  test  routine  sequence.  During  the  diagnostic  mode,  the  bus 
coutroller/processor  reassigns  priorities  to  the  unit  under  evaluation. 

Depending  upon  the  complexity  of  the  system  under  test,  a small  scratch 
pad  memory  can  be  selectively  called  in  to  record  operations  and  information 
between  successive  data  update  periods. 


The  SSIU  can  be  interfaced  to  a variety  of  system  types;  analog,  digital, 
discrete,  or  synchro,  albeit  the  synchro  interface  should  be  avoided  if  possible. 
In  the  operational  test  mode,  it  uses  the  on-board  resident  operational  memory. 
Also,  by  reassignment  of  the  SSIU  registers  and  rewriting  of  the  processor 
memory  with  diagnostic  test  routines,  it  can  conduct  an  extensive  evaluation  of 
the  connected  avionics  end  items  with  no  additional  hardware  interconnection. 


A very  valuable  capability  of  this  organization  level  AGE  concept  is  the 
ability  to  restructure  the  test  using  the  vehicle  processor.  The  initial  inter- 
connect design  must,  of  course,  contain  all  the  pinouts  that  wall  be  used  in 
subsequent  testing.  However,  this  is  not  a serious  design  consideration  for 
the  vehicle  designer  because  the  SSIU  ar$  the  avionics  end  item  are  intimately 
connected  and  are  designed  by  the  end  item  designer.  The  vehicle  designer  is 
only  concerned  with  interconnecting  the  digital  data  bus  and  associated  termi- 
nals. 


Each  vehicle  avionics  end  item  employs  a modular  software  package  which 
is  individually  addressed  through  the  MTU  and  the  SSIU.  It  is  presumed  that 
future  avionics  systems  will  be  designed  originally  for  a data  bus  interface  and 
the  expedience  of  using  SSIUs  to  interface  and  the  expedience  of  using  SSIUs  to 
interface  the  end  items  with  the  MTU  will  eventually  be  eliminated. 

The  vehicle  processor  will  maintain  all  data  update  rates  during  the  vehi- 
cle free-flight.  These  will  be  assigned  by  the  avionics  system  designer.  The 
AGE  system  test  designer  will  select  data  update  rates  as  required  to  satisfy 
the  particular  test  in  progress.  Typically,  the  test  sequence  will  address 
only  the  subsystem  under  test  and  possibly  enter  a finite  forcing  input  to  any 
associate  subsystem  that  would  normally  be  connected  to  that  subsystem  during 
normal  free-flight  operations. 


The  word  formats  employed  will  eventually  conform  to  MIL-STD-1553  and 
are  reproduced  in  Figure  3.  A hypothetical  message  format  separated  into 
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five  data  words,  both  from  and  to  the  controller  is  displayed  in  Figure  4.  This 
provides  a digital  update  data  rate  in  excess  of  3 Kbits.  Several  published 
RPV  simulation  studies  have  identified  vehicle  aerodynamic  performance 
limits  to  be  less  than  20  Hz,  well  within  the  data  rates  attainable  on  the  digital 
data  bus. 
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Figure  3.  Bit  Time  Association  With  the  Various  Word 
Formats  Used  in  MIL-STD-1553.  Command 
and  Status  Word  Formats  Permit  a Flexible 
Instruction  Set. 
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f igure  4.  Message  Formatting  for  Preliminary  Multiplex 
Digital  Data  Bus. 


Ideally,  the  on-board  processor  system  would  contain  memory  sufficient 
for  normal  free-flight  operations,  with  built-in-test  monitor,  prelaunch  con  - 
trol and  the  AGE  organizational  level  test  functions.  However,  the  cost  of 
core  memory  is  sufficiently  high  to  warrant  over-writing  the  on-board  mem- 
ory with  ground -b;ised  test  instruction  for  conducting  the  AGE  diagnostic  test 
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upon  suspect  systems.  Accordingly,  on-board  in-residence  test  routines  are 
recommended  for  the  flight  mission  and  re-assignable  test  routines  from  an 
external  tape  reader  for  extensive  diagnostic  tests. 


The  use  of  the  digital  data  bus  as  the  intercommunication  link  between  the 
end  item  and  the  console  reduces  the  number  of  pinouts  and  associated  buffer- 
ing that  would  otherwise  be  necessary. 

The  air  vehicle  processor  will  have  a unique  and  ordained  set  of  device 
codes  along  with  the  usual  transmit,  receive,  inhibit,  busy,  and  other  control 
flags.  Minor  system  test  parameter  controls  can  be  employed  to  simplify  the 
test  operation.  Standard  tolerances  should  be  assigned  to  all  similar  measure- 
ments, along  with  a standard  resolution  requirement.  All  data,  to  and  from 
the  manual  input/output,  except  dedicated  formatted  single-key  callups  and 
displays  should  be  BCD  coded  to  simplify  operator  interpretation.  From  an 
operational  standpoint,  the  processor  is  validated  continuously  during  the  nor- 
mal operating  period  by  using  the  processor  operating  in  the  self-assessment 
background  mode. 


Construction  of  a practical  integrated  organizational  level  test  set  incorporates  the 
multiplexed  digital  data  bus  terminal  as  well  as  the  computer  I/O  bus. 


The  adoption  of  the  digital  data  bus  in  the  air  vehicle  avionics  offers  the 
AGE  support  system  designer  the  ability  to  individually  assess  each  vehicle 
subsystem  and  conduct  a prelaunch  readiness  confidence  test,  or  upon  failure, 
to  conduct,  in  detail,  an  extensive  diagnoses  of  the  affected  system.  There 
are  two  limitations  which  restrict  location  of  the  test  set  with  respect  to  the 
vehicle;  all  elements  must  be  within  20  feet  of  each  other  and  the  vehicle  must 
be  designed  to  provide  simplified  access  to  the  RPV  computer  I/O  and  memory 
bus.  Figure  5 illustrates  the  system  interconnection. 


The  major  elements  of  this  system  are: 

• A programmer's  control  panel  for  the  specific  computer  used  in  the 
vehicle. 

• A keyboard  input/output  device  and  control  display  unit. 

• A magnetic  tape  memory  device. 


? 


; 
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Figure  5.  Organizational  Checkout  Console  Showing 
Interconnection  of  External  Ground-Based 


Equipment  to  the  RPV  Using  the  Computer 
I/O  Bus  and  the  Serial  Digital  Data  Bus. 


• A precision  air  data  pressure-vacuum  simulator. 

• A communications  module  similar  to  that  employed  in  the  vehicle, 
containing: 


- A data  encoder  and  decoder  interfacing  to  the  vehicle 
communications  moden  clock. 

- A low -power  omni  transmitter  and  receiver. 

The  computer  control  panel  permits  the  operator  to  directly  access 
memory  locations  and,  thereby,  load  new  programs  into  the  RPV  memory. 

This  permits  the  loading  of  any  program,  mission,  or  diagnostic  and  valida- 
tion of  the  load  prior  to  launch. 

The  keyboard  is  used  to  communicate  to  the  computer.  It  permits  the 
operator  to  conduct  tests  and  evaluate  diagnostics.  The  control  display  unit 
employs  single  key  callups  for  simplified  operator  action  when  a predetermined 
test  can  be  selected. 
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The  communications  module  permits  a complete  end-to-end  RF  link  checl 
to  be  performed. 

The  normal  prelaunch  checkout  contains  the  minimum  number  of  tests 
practical  and  consistent  with  a high  confidence  level.  These  tests  are  resi- 
dent in  the  airborne  computer  memory  core  and  are  exercised  in  one  of  two 
modes:  the  airborne  self-assessment  mode  or  with  a pre-emptive  request 
from  the  launch  control  panel.  These  command  and  response  monitor  func- 
tions use  the  normal  serial  format  high-speed  data  umbilical  interface. 

Consider  now  a case  wherein  the  pre-assigned  checkout  memory  storage 
does  not  provide  full  analytical  capability;  the  direct  memory  access  to  the 
computer  can  be  used  to  augment  the  RPV  computer.  The  magnetic  tape  unit 
containing  complete  diagnostic  routines  for  the  vehicle  and  associated  check- 
out equipment  is  used  to  load  the  RPV  computer  memory.  Because  of  the 
over-laying  of  the  memory,  the  computer  control  panel  having  memory  loca- 
tion control  is  required.  The  keyboard  input/output  is  then  used  to  perform 
any  test  desired. 

Figure  6 shows  the  signal  flow  loop  for  the  following  uplink  test  condition. 
The  computer  issues  a remote  command  instruction  which  is  addressed  to  the 
external  test  communication  interface  modem  and  receiver  transmitter  (RT). 
The  radiated  signal  is  received  by  the  RPV  RT  modem,  decoder  and  via  the 
multiplexed  data  bus  for  final  address  at  a particular  subsystem.  The  subsys- 
tem response  is  routed  through  the  multiplexed  data  bus  - computer  and  exter- 
nal keyboard  unit/control  display  unit.  Diagnostics  results  are  then  displayed. 

Figure  7 shows  the  reverse  data  loop  for  downlink  monitor  function.  In 
this  case,  the  computer  instruction  sends  the  command  to  the  vehicle  subsys- 
tem which  then  sends  its  response  through  the  multiplexed  data  bus  to  the 
encoder/decoder,  modem  and  RT.  The  test  set  RT  receives  the  radiated  sig- 
nal thence  to  the  communications  buffer  and  back  through  the  I/O  bus  to  the 
RPV  computer.  The  computer  processes  the  data  and  sends  back  results 
through  the  I/O  bus  to  the  display  unit  for  observation  and  subsequent  action. 

Upon  completion  of  any  extensive  diagnostics,  the  RPV  flight  program  is 
then  reloaded  and  verified.  Any  peculiar  navigation  mission  constants  can  be 
loaded  using  the  serial  data  (umbilical)  line. 
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The  hardware  contained  in  the  digital  data  bus  confidence  checkout  set  can 
be  easily  adapted  to  small  "building  block"  ATE  with  the  addition  of  the  appro- 
priate building  blocks  (scanners,  digital  voltmeters,  signal  generators,  etc.). 
This  could  then  provide  a common  equipment  base  for  bench-field  level  equip- 
ments. 


It  is  concluded  that  adoption  of  the  multiplexed  digital  data  bus  for  RPVs  offers 
many  benefits.  One  major  advantage  is  the  high-speed,  organizational  level  AGE  concept 
which  provides  cost  effective  performance  when  compared  to  conventional  test  methods. 

The  fly-by-wire  concept  is  a way  of  life  for  RPVs.  Control  signals  are 
either  remotely  linked  via  a radio  command  or  generated  as  a result  of  an  on- 
board flight  control  and  programming  computation.  The  multiplexed  digital 
data  bus  is  a future  vehicle  avionics  system  interconnection  method.  This 
technique  permits  simple  vehicle  avionics  equipment  modification  without 
major  vehicle  wiring  changes.  It  eliminates  a large  unwieldty  ground-based 
computer  from  the  AGE  complement  and  cooperatively  uses  the  on-board  vehi- 
cle computer  for  conducting  AGE  tests.  It  reduces  operator  skill  levels, 
connect/disconnect  and  test  time,  increases  the  number  of  tests,  and  at  the 
same  time  improves  quality  of  the  tests  performed. 

This  ability  to  conduct  rapid,  accurate  prelaunch  validation  together  with 
the  extended  capability  to  perform  individual  suspect  subsystem  diagnostic 
analyses  provides  a versatile,  effective  AGE  test  system.  Military  standardi- 
zation of  the  data  bus  multiplex  terminal  unit  hardware  promises  to  signifi- 
cately  reduce  cost  and  enable  more  universal  applications. 
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ABSTRACT 


STORES  MANAGEMENT  SYSTEM 


A wide  variety  of  weapon  control  systems  are  in  use  today  in  tactical 
aircraft.  Although  their  functions  are  similar,  each  system  is  peculair 
to  its  aircraft  or  weapon.  Hardware  complexity  is  presenting  a major 
problem  by  reducing  overall  aircraft  mission  reliability  and  aircraft 
flexibility.  Current  development  of  more  sophisticated  weapons  demands 
a better  approach  to  stores  management. 

The  Armament  Laboratory  has  initiated  development  of  a Digital  Integrated 
Stores  Management  System  (SMS)  capable  cf  adapting  to  a wide  variety  of 
weapon  systems  and  aircraft.  The  system  is  fully  programmable  providing 
adaptation  to  future  systems  with  only  software  changes.  The  system  is 
controlled  by  pilot  inputs  through  a small  number  of  discrete  switches 
and  an  integrated,  programmable  display  panel.  A digital  computer  (Main 
Logic  Unit)  processes  the  pilot  inputs  and  other  data  provided  by  aircraft 
discretes  (gear  up,  weight  on  wheels,  etc)  and  avionics  system  (Fire 
Control  System,  Bomb/Nav  Computer,  etc.)  and  sends  the  appropriate  control 
signals  to  aircraft/store  interface  units  over  a MIL-STD-1553  time-division 
multiplex  data  bus.  Release  and  control  signals  are  encoded  into  a 
multibit  field  which  require  proper  decoding  prior  to  command  execution. 

The  software  is  modularly  constructed  to  minimize  the  magnitude  of  change 
required  to  adapt  the  digital  SMS  to  new  aircraft  or  expanded  weapon 
capabilities. 
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Avionics  Multiplexing  With  Smart  Terminals 


This  is  an  update  of  earlier  work  reported  at  NAECON  '75  on  the 
use  of  microprocessors  in  multiplexed  data  terminals.  The  NAECON  paper 
described  the  organization  of  "Smart  Terminals",  their  operation  and 
potential  applications.  This  report  describes  some  of  the  applications 
either  currently  in  development  or  proposed  for  development. 


Within  the  past  year,  the  Smart  Terminal  concept  has  been  applied 
to  several  developmental  systems,  studies  and  proposed  systems. 

Generally  these  systems  have  been  designed  to  MIL-STD-1553A  and/or 
G-85013  requirements,  are  dual  redundant  and  use  a fast  microprogrammable 
processor  to  satisfy  message  and  protocall  requirements.  Bus  interface 
I/O  operations  are  under  interrupt/program  control.  This  approach  mini- 
mizes the  amount  of  hardware  which  would  be  required  if  a direct  memory 
access  (DMA)  approach  were  used.  Since  any  one  terminal  in  a system 
has  a very  limited  and  defined  interval  of  time  for  bus  operation  the 
microprocessor  can  be  used  for  special  I/O  functions. 


A high  speed  microprocessor  such  as  the  Intel  3000  Bipolar 
processor  is  therefore  necessary  to  handle  direct  program  control  of 
I/O  operations.  Special  microprogrammed  instructions  have  been  formu- 
lated to  further  reduce  time  needed  to  service  the  multiplexed  data  bus. 

Specific  Smart  Terminal  applications  currently  in  development, 
study  or  proposed  for  development  are  as  follows. 

1.  Pilot's  Cockpit  Weapons  Control  Panel  - Eglin  AFB 

2.  Bus  Monitor  Interface  Unit  - WPAFB 

3.  Solid  State  A/C  Electric  Power  Control  - NADC 

4.  Integrated  Avionics  Control  System  - USA/ECOM 

A brief  description  of  the  above  multiplexed  avionics  systems  is 
provided  in  the  following  paragraphs. 

Pilots  Cockpit  Weapons  Control  Panel 


The  pilots  control  panel  (PCP)  is  currently  under  development  for 
Eglin  Air  Force  Base.  It  is  a good  example  of  the  application  of  multi- 
plexed terminal  using  microprocessors.  It's  function  is  to  provide  a 
crew  interface  control  and  display  panel  for  developmental  multiplexed 
armament  control  system. 

Figure  I shows  the  front  face  of  the  PCP  lighting  mockup  which 
contains  72  sixteen  segment  alphanumeric  characters,  6 associated  mode 
control  switches  and  10  interactive  program  switches.  Functions  such  as 
display  refresh,  ASCII  to  16  segment  conversion,  switch  sampling  and 
miscellaneous  test  functions  are  performed  by  the  internal  microprocessor 
which  also  controls  and  services  the  multiplexed  data  bus. 

A block  diagram  of  the  control  panel  is  shown  in  figure  2.  The 
system  is  tied  into  a dual  redundant  MIL-STD-1553A  data  bus.  Dual 
redundancy  is  carried  to  the  point  where  the  front  end  interfaces  with 
the  microprocessor.  Thereafter  the  system  is  single  string. 

The  interface  logic  between  the  data  bus  and  the  microprocessor  is 
implemented  via  specially  designed  hybrid  circuits.  Four  hybrids  sure 
used  to  interface  each  of  the  dual  redundant  bus  interface  paths  to  the 
microprocessor.  The  trsuisceiver  is  comprised  of  2 hybrids,  a receiver 
and  a transmitter  (fig.  3) . The  transmitter  consists  of  two  identical 
output  drivers,  driven  by  a shaped  signal.  This  provides  an  output 
waveform  with  controlled  rise  and  fall  times  within  the  1553A  require- 
ments. The  receiver  has  high  common  mode  rejection  and  incorporates 
active  filters.  All  data  passes  through  the  next  hybrid  fig.  4,  the  MDR. 
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This  unit  detects  and  generates  sync,  strobe  and  Manchester  signals,  it 
also  checks  sync  and  data  timing  and  data  dropout.  The  interface  between 
the  MDR  and  the  Buffer,  (the  forth  hybrid,  fig.  5)  the  NRZ  data  and 
control  signals.  The  Buffer  hybrid  essentially  performs  the  serial/ 
parallel  and  parallel/serial  conversions  necessary  for  interfacing  with 
a processor.  Although  an  8 bit  interface  between  buffer  and  microprocessor 
is  shown,  the  buffer  hybrid  has  been  designed  to  also  handle  a 16  bit 
processor  interface.  Simple  external  wiring  is  used  to  change  the 
hybrid  operation  for  16  or  8 bit  operations. 

The  right  side  of  the  block  diagram  represents  the  I/O  required  for 
the  front  panel  displays  and  switches  as  well  as  external  switch  input 
discretes  and  A/D  converter  signals.  All  of  these  I/O  devices  operate 
directly  off  the  8 bit  microprocessor  data  bus.  Control  signals  are 
generated  by  the  microprocessor  to  steer  the  8 bit  bos  data  to  appro- 
priate output  devices  or  to  sample  specific  input  devices. 

Display  data  is  converted  by  the  microprocessor  from  ASCII  to  16 
segment  alphanumeric  display  data.  The  display  data  is  latched  and 
periodically  strobed  (80  times  per  second)  by  the  microprocessor  to 
provide  display  refresh. 

Solid  State  Electric  Power  Control  (SOSTEL) 


This  work  was  performed  to  provide  a realistic  baseline  for  the 
development  of  the  Advanced  Aircraft  Electric  System  (AAES)  using  multi- 
plexed control  avionics.  The  Navy  F-14A  aircraft  was  utilized  as  the 
baseline  vehicle  for  the  study  from  which  a resultant  data  base  was 
developed . 


The  AAES  is  a system  employing  advanced  concepts  for  aircraft 
power  generation  and  distribution.  It  is  designed  to  replace  the  exist- 
ing integrated  drive  generators  and  the  electromechanical  switching  and 
distribution  of  power  presently  utilized  in  the  majority  of  aircraft. 

The  AAES  consists  of  the  Solid  State  Electric  Logic  (SOSTEL)  and  the 
General  Purpose  Multiplexing  System  (GPMS)  for  power  control,  distribu- 
tion and  protection.  It  utilizes  a constant  frequency  generator  (CFG) 
or  high  voltage  DC  for  primary  aircraft  power  generation. 

The  SOSTEL/ GPMS  systems  employ  multiplexing  and  time  division  data 
bus  concepts  for  the  transmission  of  information  and  are  consistant  with 
MIL-STD- 1 55 3A  and  G-85013  data  bus  formats  and  requirements.  GPMS 
(G85013)  uses  a polling  system  concept  employing  remote  data  terminals 
(DT's),  a central  cable  control  unit  (CCU)  and  twisted  pairs.  It  is  a 
general-purpose,  nondedicated  asynchronous  system  capable  of  interfacing 
with  a wide  variety  of  signal  types.  Its  application  includes  flight 
control,  weapon  control,  display,  communication,  navigation,  and  identi- 
fication subsystems  as  well  as  power  distribution  and  control.  In  this 
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study  it  was  primarily  viewed  as  a system  which  would  provide  the  trans- 
mission facilities  (data  buses)  for  the  SOSTEL  system.  This  implies  that 
the  system  analysis  and  requirements  for  the  implementation  of  a complete 
GPMS  system  has  not  beer  performed  yet.  However,  its  interface  and 
operation  as  applied  to  SOSTEL  were  examined  and  a full  up  system  is 
being  studied  now.  In  particular  the  operation  of  a synchronous,  time- 
shared  SOSTEL  command  response  system  was  examined  relative  to  its  opera- 
tion as  part  of  an  asynchronous  GPMS  polling  system.  In  addition,  it  is 
utilized  to  provide  sink  and  source  terminal  for  signals  which  were  not 
compatible  with  the  SOSTEL  system. 

The  SOSTEL  system  is  capable  of  providing,  either  in  conjunction 
with  GPMS  or  by  itself,  the  control  and  distribution  capability  of  an 
aircraft  power  distribution  system.  It  utilizes  solid  state  power  con- 
trollers to  provide  the  power  switching  and  protection  presently  imple- 
mented by  electromechanical  circuit  breakers,  relays  and  switches.  It 
utilizes  solid  state  transducers  as  replacements  for  the  present  power 
control  signals  sources  (manual,  mechanical,  thermally,  pressure 
actuated  switches,  etc).  Remotely  located  demultiplexers  (DEMUX)  and 
multiplexers  (MUX)  are  employed  to  control  the  solid  state  power  con- 
trollers and  sample  the  solid  state  transducers . Master  units  (MU's) 
containing  digital  processors  provide  control  of  the  SOSTEL  system  as 
well  as  solutions  to  the  power  Boolean  equations.  The  equations  are 
equivalent  to  the  present  power  paths,  where  power  leads  are  routed 
through  the  aircraft  switches  and  relays  for  power  control  to  a weapon 
replaceable  assembly  (WRA) . 

Smart  terminals  can  be  used  to  off-load  the  MU  by  evaluating  data 
at  the  terminal  and  only  transmitting  data  when  changes  occur  or  on 
special  command.  The  terminal  can  also  perform  all  of  the  test  functions 
required  at  the  terminal  location.  This  results  in  the  processor  only 
solving  equations  which  have  changed  and  require  action  on  the  part  of 
the  system  or  crew.  Periodic  update  of  all  equations  can  be  performed 
on  a low  priority  basis. 

The  F-14  power  generation  and  distribution  system  was  analyzed,  the 
loads,  transducers,  and  power  Boolean  equations  were  catalogued.  This 
information  was  used  to  identify  the  number  and  types  of  components  in 
the  GPMS/ SOSTEL  system.  A physical  review  of  the  F-14  identified  loca- 
tions for  installation  of  components.  A thermal  analysis  was  performed 
to  ensure  the  survival  of  the  components  in  their  assigned  locations. 

A preliminary  reliability  analysis  of  the  AAES  system  and  components  was 
performed.  Various  PGS  configurations  were  analyzed,  the  internal  re- 
dundancy requirements  of  the  SOSTEL  Group  III  components  were  reviewed, 
and  the  thermal/reliability  requirements  of  the  solid  state  controller 
configurations  and  installations  were  identified.  As  a result  the  idea 
of  internal  redundancy  appears  to  be  questionable  value  based  on  a cost 
benefit  trade  off.  It  also  is  not  satisfactory  for  meeting  survivability 
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requirements,  in  this  case  redundancy  must  be  in  separate  units  and 
locations.  The  requirements  and  routines  required  by  the  master  unit 
processor  were  examined  to  determine  the  memory  and  computational  load 
requirements.  In  addition,  the  SOSTEL  interface  to  the  power  generation 
system  was  analyzed  to  identify  the  parameters  the  SOSTEL  system  would 
monitor  to  ensure  compatibility  between  power  generation  and  power  dis- 
tribution. SOSTEL  priorities  and  techniques  for  providing  power  to 
essential  loads  during  emergency  modes  of  operation  were  developed  using 
the  present  F-14A  aircraft  multibus  configurations  as  a baseline. 

The  crew  control  and  display  (CCDP)  design  requirements  were  in- 
vestigated and  an  alphanumeric  interactive  control  display  unit  was 
described.  The  design  of  MUX  and  DEMUX  terminals  configured  about  "dual" 
in-line  MSI  and  LSI  as  well  as  a "Smart"  unit  utilizing  an  Intel  3000 
microprocessor  is  discussed.  The  installation,  thermal,  reliability  and 
mechanical  considerations  and  design  of  an  AAES-configured  F-14A  was 
developed. 

Figure  6 is  a block  diagram  of  a multiplexed  solid  state  electric 
power  control  system  configured  for  the  F-14A.  The  configuration  is 
some  what  of  a hybrid  arrangement.  Two  data  buses  are  dedicated  to  the 
power  control  function  as  are  MUJ^  DEMUX  and  MUL/DEMUX  terminals.  These 
data  terminals  operate  as  a conned/ response  mode. 

A General  Purpose  Multiplex ^System  (GPMS)  is  tied-in  to  handle  non- 
power control  signals  and  operates  on  its  own  two  time  shared  buses. 
Additionally  the  GPMS  is  interfaced  with  the  dedicated  power  control 
buses  for  transfer  to  low  power  loads,  discretes  and  flags. 

♦ 

An  alternate  configuration  using  all  GPMS  type  of  terminals  design 
around  a microprocessor  has  been  evaluated.  This  approach  permitted  use 
of  SOSTEL  and  NON-SOSTEL  IvO 1 s in  one  unit  and  resulted  in  a 60%  reduc- 
tion in  the  number  of  terminals  required  in  a full -up  system. 

Integrated  Avionics  Control  System 


This  system  provides  integrated  control  of  helicopter  CNI  airborne 
equipments.  The  system  consists  of  3 cockpit  control/display  panels  of 
differing  levels  of  capability  and  complexity.  In  addition  2 central 
control  units,  located  in  the  equipment  bay,  control  the  remotely 
located  CNI  equipments .v 

Figure  7 is  a block  diagram  of  the  proposed  system  showing  dual 
redundant  MIL-STD  1553A  data  buses.  The  two  main  units  in  the  system 
are  the  primary  CCU  and  the  primary  peine 1 . The  primary  CCU  micropro- 
cessor is  normally  in  control  and  performs  the  function  of  data  bus  con- 
troller on  eithew  bus  as  well  as  controlling  the  I/O  for  the  majority 
of  CNI  equipments.. 


Smart  terminals  using  the  3000  microprocessor  are  used  for  data  bus 
operations  and  data  handling  for  display/control  and  equipment  interfacing. 
This  design  provides  the  bus  control  function,  which  is  very  simple  and 
could  be  integrated  into  a larger  multiplex  system  where  the  bus  control 
is  provided. 

Backup  modes  are  designed  into  the  system  so  that  a single  failure 
will  not  cause  the  loss  of  the  full  system. 

The  secondary  central  control  unit  provides  a minimum  communications 
capability  as  a backup  to  the  primary  CCU.  The  secondary  control  panel 
likewise  provides  backup  capability  to  the  primary  control  panel.  This 
system  arrangement  thus  permits  failure  of  several  level  of  system  ele- 
ments while  maintaining  operational  integrity. 

Several  features  have  been  added  to  previous  smart  terminal  multi- 
plexed systems.  The  use  of  multiple  remotely  located  terminals,  which 
may  act  as  bus  controller  is  new.  This  also  permits  interaction  during 
fault  detection  and  isolation  routines  which  results  in  better  system 
self  test.  In  the  area  of  the  bus  interface  unit  we  plan  to  combine  the 
MDR,  and  BUFFER  into  LSI's  for  further  area,  volume,  and  cost  reductions. 
The  hybrid  receiver/transmitter  discussed  previously  will  remain  as  is. 

I/O's  to  the  user  subsystems  are  to  be  mechanized  via  hybrid  or  LSI 
technology  since  there  is  a fair  amount  of  I/O  commonality. 

Smart  Terminal  Software 

Software  development  for  Smart  Data  Terminals  has  proceeded  on  the 
basis  of  3000  Bipolar  processor.  Micro  and  Macro  Assemblers  have  been 
developed  for  the  16  bit  processor.  These  were  modified  to  accomodate  an 
8 bit  version  of  the  3000  processor.  The  8 bit  smart  terminal  has  been 
generally  applied  in  applications  where  logic  and  simple  arithmetic 
operations  are  required.  The  16  bit  versions  provide  the  precision 
necessary  for  complex  mathematical  operations.  The  sixteen  bit  design 
also  provides  a higher  throughput  since  the  entire  data  field  is  handled 
in  a single  input/output  operation. 

Instruction  sets  developed  for  the  smart  terminals  consist  of  over 
100  standard  computer  instructions  devised  to  minimize  the  number  of 
steps  necessary  to  move  data  between  registers,  memory,  accumulator  and 
I/O.  Special  instructions  have  been  formulated  to  facilitate  the  multi- 
plexed data  bus  I/O  operations.  This  class  of  microcoded  instructions 
minimizes  the  time  required  to  perform  computer/bus  interface  operations 
associated  with  the  requirements  of  MIL-STD-1553A  and  G85013. 

The  Grumman  Microassembler,  MCMAP,  is  a real-time  interactive  pro- 
gram which  permits  a programmer  to  enter  and  manipulate  the  mnemonic 
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language  of  the  3000.  It  provides  a load  tape  of  microsequences  which 
define  the  desired  assembly  language,  and  documentation  in  the  form  of 
micromemory  maps  and  instruction-by-instruction  traces  of  individual 
sequences.  MCMAP  has  been  used  to  generate  an  assembly  language  which 
provides  efficient  data  handling  capabilities.  The  MCMAP  microassembler 
is  a developmental  software  package  used  in  processor  development. 

Table  1 is  a tabular  description  of  the  Primary  Assembly  Language 
for  the  3000  processor,  showing  the  number  of  main  memory  words  required 
to  implement  the  instruction  and  the  number  of  microcycles  for  fetching 
immediate  data  and  the  subsequent  instruction  from  main  memory. 

The  Grumman  Assembler,  MCGAP,  is  a three-pass  assembler  program 
which  converts  source  programs  written  in  the  Primary  Assembly  Language 
into  object  programs  for  loading  the  3000  main  memory.  The  MCGAP  as- 
sembler forms  the  basis  for  user  software  development  and  modifications. 
The  assembler  has  the  unique  capability  of  accepting  the  assembly  lang- 
uage opcode  file  directly  from  the  MCMAP  microassembler  so  as  to  support 
all  instructions  which  have  been  established  as  micro-sequences.  The 
assembler  is  currently  programmed  for  8 and  16-bit  word  object  codes. 

Basic  feature  are: 

o Common  Data  or  Compool  capability 
o Multiple-error  diagnostics 
o Program  check-sum  generation 
o Full-page  comment  capability 

Typical  software  functions  illustrated  below  are  those  required  for 
implementation  of  the  Pilots  Control  Panel  mentioned  earlier. 

FOREGROUND  PROGRAM  I 


o Receive  Data  from  Data  Bus  and  Buffer  it 
o Transmit  back  requested  data 
o Error  handling  (parity,  idle  line) 
o Status  word  transmission 
o Bus  test  function 
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FOREGROUND  PROGRAM  II 


o Display  refresh  column  by  column 
o Output  Lamp  Control  Bits 
o Input  Switch  Data 
o Input  Slew  Data 
BACKGROUND  PROGRAM  I 

o Update  of  refresh  buffer  from  received  message 
o Format  data  for  lamp  control  from  received  message 
o Handle  transmitter  shut  down  command 
BACKGROUND  PROGRAM  II 


o Format  data  for  response  to  switch  queries 
(Program,  Mode  and  External  Switches) 

o Display  Self  Test 

o Watchdog  Monitoring  and  Software  Self  Test 

Experience  with  smart  terminal  software  during  a development  phase 
has  been  favorable . Changes  which  have  occurred  during  design  have  been 
easily  handled  via  software.  Thus  once  the  basic  Bus  Interface  and 
Microporcessor  have  been  designed  to  satisfy  MIL-STD-1553A  requirements, 
that  portion  of  the  design  is  fixed  and  does  not  change.  The  remaining 
hardware  design  is  related  to  the  specific  application  and  user  I/O. 
Thereafter  any  design  changes  associated  with  operational  functions  for 
the  specific  user  application  can  be  readily  handled  via  software. 

CONCLUSIONS 


Multiplexed  data  terminals  using  microprocessor  are  receiving  more 
and  more  attention  by  both  the  military  and  industry.  As  noted  by  the 
types  of  applications  discussed  herein,  it  can  be  seen  that  a trend  is 
evolving.  Users  in  particular  technical  disciplines  are  independently 
applying  the  concept  of  the  smart  data  terminal. 
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Current  applications  include: 

1 . Armament  control  and  display 

2.  Communications  control  and  display 

3.  Electric  power  control  and  display 

4.  Engine  instrumentation  monitoring,  recording  and  display. 

Future  applications  include  potential  for  navigation,  flight 
control  and  other  suitable  aircraft  areas. 

It  is  expected  as  confidence  is  gained  in  individual  technologies 
using  microporcessor  based  multiplex  terminals,  that  higher  level  dis- 
tributed processor  avionics  systems  will  evolve.  This  trend  should 
accelerate  as  the  microprocessors  and  their  peripheral  devices  now  in 
development  become  available. 
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Figure  2 Pilot's  Control  Panel  - Block  Diagram 


Figure  5 


TABLE  1 PRIMARY  ASSEMBLY  LANGUAGE 


Intt  Hex. 

Mnem.  Velue 

Words 

Micro 

Cycles 

1 COMPUTER  CONTROLS 

El  OB 

1 

4 

IN  0E 

1 

7 

LD 

TDB 

- 

LK  OF 

1 

3 

NO  00 

1 

4 

ST  FF 

1 

9 

II  UNCONDITIONAL  JUMPS 

JIM  3E 

2 

7 

JIN  3F 

2 

8 

JMP  28 

2 

5 

JSR  3D 

2 

8 

RET  ID 

1 

6 

III  CONDITIONAL  JUMPS 

JAN  2A 

2 

7 

JAP  3A 

2 

8 

JCF  19 

2 

5 

JZF  2F  2 

IV  LOOPING  JUMPS 

5 

OBJ  2C 

2 

6 

DCJ  2D 

2 

6 

JNZ  2E  2 

V REGISTER  INIT. 

6 

CLRA  01 

1 

4 

CLRB  02 

1 

4 

CLRC  03 

1 

4 

CLZF  04 

1 

4 

MVI A 10 

2 

6 

MVIB  20 

2 

6 

MVIC  36 

2 

8 

VI  REGISTER  MOVES 

MVBA  12 

1 

5 

MVCA  13 

1 

5 

MVUA  46 

1 

5 

MVXA  42 

1 

5 

MVAU  44 

1 

5 

MVAX  45 

1 

5 

MVAB  21 

1 

5 

MVCB  23 

1 

5 

MVVB  56 

1 

5 

MVYB  51 

1 

5 

MVBV  54 

1 

6 

Inst 

Hex. 

Micro 

Mnem. 

Value 

Words  Cycles 

VI  REGIS.  MOVES  (CONT) 


MVBY 

55 

1 

5 

MVAC 

31 

1 

5 

MVBC 

32 

1 

5 

MVWC 

66 

1 

5 

MVZC 

61 

1 

5 

MVCW 

64 

1 

5 

EXSC 

B8 

1 

8 

VII  LOADS 

MVMA 

16 

2 

8 

MVMB 

26 

2 

6 

MVMC 

36 

2 

8 

MVNA 

17 

2 

9 

MVNB 

27 

2 

9 

MVNC 

37 

2 

9 

VIII  STORES 

MVAM 

48 

2 

7 

mvbm 

58 

2 

7 

MVCM 

74 

2 

6 

MVAN 

49 

2 

8 

mvbn 

59 

2 

8 

IX  STACK  OPS 

MVCP 

4A 

1 

5 

MVPC 

7D 

2 

5 

POPA 

40 

1 

7 

POPB 

50 

1 

7 

POPC 

60 

1 

7 

POPF 

7B 

1 

7 

PSHA 

4F 

1 

5 

PSHB 

5F 

1 

S 

PSHC 

77 

1 

5 

PSHF 

7A 

1 

6 

X INCREMENTS 

DCRA 

A2 

1 

4 

INRA 

A3 

1 

4 

INRB 

83 

1 

4 

INRC 

C3 

1 

4 

INRM 

E0 

2 

8 

INRN 

El 

2 

9 

XI  ARITHMETIC 

ADAB 

B0 

1 

5 

AOAC 

CO 

1 

S 

Inst 

Hex. 

Micro 

Mnem. 

Value 

Words  Cyder 

XI  ARITHMETIC  ICONT) 


ADAM 

F0 

2 

6 

ADAN 

FI 

2 

9 

ADIA 

A1 

2 

6 

ADIB 

B1 

2 

6 

ADIC 

Cl 

2 

6 

SUAB 

B2 

1 

6 

SUAC 

C2 

1 

6 

TWOA 

A4 

1 

5 

TWO  8 

64 

1 

5 

XII  SHIFTS 

LOAA 

D6 

1 

S 

LOAB 

A5 

1 

7 

ROAA 

DO 

1 

6 

ROAB 

E2 

1 

9 

ROBB 

E3 

1 

6 

XIII  LOGIC 

ANBA 

8B 

1 

5 

ANCA 

8C 

1 

5 

ANIA 

8A 

2 

6 

ANMA 

88 

2 

8 

ANNA 

89 

2 

9 

ONEA 

06 

1 

4 

ONEB 

C4 

1 

4 

ORBA 

9B 

1 

5 

ORCA 

9C 

1 

S 

ORIA 

9A 

2 

6 

ORMA 

98 

2 

8 

ORNA 

99 

2 

9 

TSZF 

05 

1 

4 

XRBA 

AB 

1 

6 

XRCA 

AC 

1 

6 

XRI A 

AA 

2 

6 

XRMA 

A8 

2 

8 

XRNA 

A9 

2 

9 

XIV  INPUT/OUTPUT 

EXAB 

70 

1 

9 

INNA 

80 

3 

11 

OUTA 

90 

3 

11 

XV  BUS  OPERATIONS 

ST01 

63 

2 

6 

ST02 

6B 

1 

S 

ST03 

6A 

1 

6 
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APPLICATION  OF  LSI  AND  HYBRID  TECHNOLOGY 
TO  AVIONIC  MULTIPLEX  SYSTEMS 


R.  Timothy  Rogers 
Singer-Kearfott  Division 


ABSTRACT 

This  paper  discusses  key  multiplex  system  parameters 
affected  by  LSI  and  hybrid  design  of  remote  multiplex 
terminals.  Terminal  functions  common  to  all  avionic  systems 
are  identified,  and  a functional  partitioning  given  as  the 
basis  for  LSI  and  hybrid  definition.  Reduction  in  volume, 
weight,  power  and  reliability  improvement  are  cited  for 
various  terminal  configurations.  Key  building  blocks  are 
defined  with  their  application  to  the  B-l,  Space  Shuttle 
and  F-16  programs  demonstrated. 
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SYSTEM  PARAMETERS 

* 

Multiplex  systems  in  general  consist  of  a number  of 
subsystem  boxes  distributed  throughout  a vehicle,  connected 
to  a common  data  bus  via  multiplex  interface  terminals.  The 
category  of  terminals  described  herein  operates  in  a time 
division,  half  duplex  mode  and  is  interconnected  in  a party 
line  configuration. 

Figure  1 illustrates  a typical  system,  which  displays 
most  of  the  elements  employed  in  systems  built  to  date. 
Characteristic  of  such  systems  is  the  redundant  data  bus 
interconnect  which  is  dual  redundant  in  most  applications 
with  increased  levels  of  redundancy  in  special  flight  critical 
systems . Subsystems  containing  MUX  terminals  are  general 
purpose  remote  terminals  that  handle  a multiplexity  of  analog, 
discrete  and  digital  signals,  special  purpose  sensor  terminals, 
system  data  entry  and  display  devices,  and  processors  that 
perform  a dual  function  of  master  bus  control  and  remote  slave 
terminal . 

Of  special  interest  is  the  fact  that  each  subsystem 
element  contains  one  or  more  multiplexing  terminals  meaning  that, 
any  improvement  in  terminal  weight,  volume,  cost,  power  or 
reliability  is  multiplied  by  the  number  of  terminals  per  system. 
The  magnification  also  means  that  small  savings,  per  terminal 
can  result  in  large  savings  per  system.  Therefore,  it  is  a 
system  goal  to  optimize  the  above  system  parameters  with  the 
possibility  of  making  a significant  improvement  in  as  many  areas 
as  possible. 

Another  class  of  parameters  of  concern  to  the  system 
engineer  are  data  transmission  performance  characteristics  such 
as  Bit  Error  Rate,  Word  Error  Rate  throughput,  failure  modes, 
redundancy,  retransmission,  I/O  scheduling,  data  loss,  software/ 
hardware  and  multiplex  data  bus.  Therefore,  it  is  a second 
goal  that  the  data  transmission  performance  parameters  are 
preserved  in  the  transition  from  discrete  circuit  technology 
to  LSI  and  hybrid  technology. 

TECHNOLOGY  COMPARISON 

A definition  of  the  multiplex  terminal  is  required  before 
a comparison  can  be  performed.  Figure  2 a general  purpose 
multiplex  terminal  consisting  of  hardware  that  processes  bits 
and  words  from  the  data  bus  to  the  subsystem  interface  is 
divided  into  a Word  Processing  section  (WP)  and  a Message 
Processing  section  (HP) . The  section  traded  off  in  Table  1 
is  the  Word  Processing  section. 
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MULTIPLEXING  SYSTEM  ELEMENTS 

FIGURE  1 
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MULTIPLEX  TERMINAL  PARTITIONING 
FIGURE  2 


Parameters  presented  in  Table  1 represent  Singer  designs 
that  exist  and  are  employed  in  current  avionic  multiplex 
programs.  Since  the  basic  transmitting  and  receiving  techniques 
have  remained  relatively  constant  over  the  interval  of  time, 
spanning  1972  to  present,  a source  of  accurate  data  was 
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available.  It  is  recognized  that  variations  in  circuit 
design  techniques  as  well  as  packaging  schemes  and  system 
environments  can  affect  the  resultant  configuration, 
therefore,  designs  were  all  translated  to  a common  set 
of  control  parameters. 


TABLE  1.  MULTIPLEX  TERMINAL  TECHNOLOGY  COMPARISON 


LSI/HYBRID 

DISCRETE 

Weight  (lbs) 

0.19  - 0.13 

*0.54  - 0.46 

Volume  (Rel . ) 

0.25  - 0.33 

1.0 

Reliability 
MTBF ( 10 3 hrs) 

151  - 300 

88  - 110 

Power  (watts) 
Consumption  of 
Logic 

0.35  - 0.1 

4.35  - 0.800 

*Two  numbers  indicate  the  range  of  existing  designs. 


In  a number  of  cases  more  than  one  design  exists  for  each 
entry  in  the  table,  and  is  indicated  by  two  sets  of  numbers. 
MTBF  figures  were  generated  using  the  same  failure  rate 
criteria  for  all  designs.  Additional  weight  savings  not 
reflected  in  the  chart  are  savings  resulting  from  reduction  in 
power  supply  requirements  or  chassis  structural  requirements. 
Additional  benefit  derival  from  the  volumetric  savings  are 
the  overall  reduction  in  the  number  or  printed  circuit 
cards,  connectors  and  associated  hardware. 

L.S.I.  AND  HYBRID  PARTITIONING 

A goal  of  L.S.I.  design  is  to  find  a broad  range  of 
applications  resulting  in  large  piece  part  procurement  to 
make  the  investment  worthwhile.  One  way  to  accomplish  this 
is  to  produce  a design  that  is  general  purpose  in  nature 
and  not  application  sensitive. 

Figure  2 was  developed  with  the  ourpose  in  mind 
to  identify  functions  that  a remote  terminal  must  perform  in 
a class  of  applications.  It  does  not  represent  an 
architecture  but  rather  functions,  independent  of  implemen- 
tation, that  are  performed  by  terminals.  It  is  true  that 
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some  of  the  message  processing  and  interface  functions  can 
be  integrated  into  the  subsystem,  however,  somewhere 
either  as  a standalone  or  integral  part  of  a system,  the 
functions  still  must  be  performed. 

A search  for  common  denominators  between  various  systems 
leads  to  the  most  obvious  partition  as  suggested  by  the 
figure.  The  analog  transmit  receive  functions  are  candidates 
for  hybridization  while  the  Word  Processing  functions  if 
designed  digitally  are  candidates  for  L.S.I.  development 
Word  processing  functions  are  independent  of  bit  assign- 
ments, field  assignments,  sync  polarity,  bit  polarity, 
sequence  of  words,  message  or  word  gaps.  They  are  dependent 
on  word  length,  sync  and  bit  encoding  only,  and  hence  are 
application  independent.  Hence,  a transparent  digital  front 
end  can  be  constructed  consisting  of  a few  components,  that 
can  be  used  in  many  applications.  Additional  L.S.I. 
development  has  been  undertaken  in  the  message  processing 
area,  but  due  to  the  uniqueness  of  system  design,  has  not 
found  widespread  usage. 

TERMINAL  DESCRIPTION 

A digital  front  end  Word  Processing  terminal  is  shown  in 
Figure  3 and  is  employed  in  the  Space  Shuttle  Program.  The 
key  elements  of  the  design  had  their  origin  in  1973  under  an 
in-house  development  program  and  were  first  employed  in  a 
B-l  Multiplex  Interface  Module  (MIM) . The  same  subset  of 
components  has  been  employed  successfully  in  other  programs, 
the  most  recent  being  the  F-16  AMUX. 

The  multiplex  module  consists  of  a transformer,  a transmit 
and  receive  hybrid,  an  encoder/ decoder  L.S.I.  chip,  a control 
and  timing  hybrid  and  four  MOS  to  T^L  buffers. 

The  interface  to  the  module  is  serial  MRZ  data  in  both 
transmit  and  receive  modes  with  the  module  deriving  the 
receive  clock  from  the  incoming  signal  and  generating  a trans- 
mit clock  from  control  logic  during  the  transmit  mode,  under 
subsystem  initiate  commands.  Sync  information  and  error 
diagnostics  are  also  provided  to  perform  a complete  MUX  inter- 
face that  permits  the  processing  of  valid  data  and  the 
detection  of  invalid  data. 

ENCODER/DECODER  LSI 

The  EDC  chip,  a significant  development  in  multiplex 
terminal  design,  replaces  approximately  twenty  MSI/SSI 
integrated  circuits  and  reduces  the  volume  of  the  remote 
terminal  by  a factor  of  2.  It  consumes  70mw  of  power  while 
running  at  a clock  rate  of  8 mega  hertz  which  is  a speed/power 
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BLOCK  DIAGRAM 
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ratio  unattainable  with  standard  components.  Designed  to  be 
compatible  with  the  T/R  hybrid,  the  pair  control  system 
performance,  attaining  a Bit  Error  Rate  figure  of  10~8  and  a 
word  error  rate  figure  of  10“7  at  a signal  to  noice  ratio  of 
14DB  under  B-l  and  Space  Shuttle  noise  environment  conditions. 
It  contains  the  detection  algorithms  for  sync  and  data  bits 
and  also  error  detection  circuitry  for  invalid  bits,  parity 
bit  count,  and  timing.  The  chip  is  implemented  with  the  CMOS 
metal  gate  process  and  operated  at  a synchronous  clock  rate 
of  8 MHz  over  the  full  military  range.  A block  diagram  is 
included  in  Figure  4 with  a set  of  characteristics  listed 
below: 


TABLE  2.  ENCODER/DECODER  LSI  CHARACTERISTICS 

• Electrical 

Technology-CMOS  Metal  Gate 
Transistors  - 1100 
Clock  Rate  - 8MHz 
Power  Dissipation  - 70  MW 
Temperature  Range  - -55°C  to  100°C 

• Interface 

Input  8 volt 

Output  8 volt/5  volt 

• Physical 

Size  A 0.64"  x 1.06"  x .087" 

Size  B 0.375  x 0.375"  x .078" 

Chip  Size  150  x 150  mils 


T/R  HYBRID 

Companion  component  to  the  EDC,  the  T/R  hybrid  provides 
the  interface  to  the  data  bus  and  controls  electrical  signal 
generation  and  reception.  The  transmitter  section  accepts  T2L 
phase  encoded  signals,  controls  the  rise  time  and  power 
amplifies  the  signals  to  data  bus  signal  levels  between  2 to 
3 watts  peak  into  a 70  ohm  cable.  Saturated  and  unsaturated 
transmitters  have  been  designed  for  various  programs.  The 
current  Space  Shuttle  transmitter  is  a saturated  type  for 
power  efficiency  reasons.  Receiver  circuitry  consists  of  an 
amplitude  clipper,  filter,  threshold  circuitry  comparators  and 
sampling  circuitry  (not  shown  in  Figure  5) . 
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Functions  of  the  receiver  are  obviously  related  to 
required  receiver  performance  levels.  The  interface  to 
the  EDC  is  at  MOS  levels  of  8 volts.  In  addition  to  the 
normal  detect  signals,  the  T/R  hybrid  contains  the  16  MHz 
clock  scaler  circuit  as  well  as  the  CMOS  8 MHz  clock  driver. 

The  T/R  provides  compatibility  to  all  the  noise  rejection  specs, 
input  impedance,  signal  response  and  is  a contributor  to  the 
error  rate  performance. 

Listed  in  Table  3 are  a few  characteristics  of  the 
circuit . 


TABLE  3.  T/R  HYBRID  CHARACTERISTICS 


Size 


1.180"  x 1.180" 


Weight 


Power 


8 . 5 grams 

1.6  watts 


Technology 


chip  capacitors,  IC's,  thin  film  resistors 


Electrical  Parameters 


Output 


15  volts  pk  into  70  ohm  cable 

Rise  and  fall  times  150  +50  nanoseconds 

Distortion  < 300  mv  p.p. 

Off  Noise  < 50  mv  p.p. 

Off  Impedance > 6800  ohms 

Input 

Noise  rejection  +6v  pk  below  1 KHz  and  above  4 MHz 
Bit  Error  Rate  10“8  (SN  = 14  DB) 

- CMV  +50v  (dc  to  2 MHz) 

Input  Signal  Level  for  proper  operation  1.5v  to  15v  p 
No  operation  0 to  0.45  pk 


APPLICATION  TO  HARDWARE  DESIGN 


The  following  tabulation  is  a list  of  hardware  delivered 
to  on-going  programs,  containing  building  blocks  of  the  subject 
L.S.I.  and  hybrid  technology. 

• B-l  Multiplex  Interface  Modules  (MIM)  - Resident  in 

Flight  Instrument  Signal  Converter  and  other  CFE  Avionic 
Subsystems 


• Space  Shuttle  - Serial  Multiplex  Interface  Adapter  (SMIA) 


- I/O  Processor  (DMIA) 

- Data  Bus  Isolation  Amplifier  (DBIA) 

- Orbiter  Bus  Simulator  MIM-A,  B 

• F-16  - Inertial  Navigation  Set  - Master/Slave  Terminal 

- Fire  Control  Navigation  Panel  - Remote  Terminal 

- AMUX  - Stores  Management  Remote  Terminal 


MICRO-PROGRAMMABLE  DATA  TERMINAL 

B.  E.  Bona 

Autonetics  Group 
Rockwell  International 
Anaheim,  California 


INTRODUCTION 


The  Micro-Programmable  Data  Terminal  (MPDT)  chip  is  a 
hardened  large  scale  integrated  CMOS/SOS  device,  designed 
for  use  in  command/response,  time  division  multiplex  systems. 
This  paper  describes  the  functions  on  the  chip,  illustrates 
how  the  chip  would  be  programmed  to  operate  in  a MIL-STD- 
1553A  data  bus,  and  suggests  how  it  would  be  applied  to 
other  avionic  multiplexing  systems  (e.g.,  B-l  and  Space 
Shuttle)  whose  word  and  message  formats  are  not  identical 
with  those  specified  in  MIL-STD-1553A. 
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GENERAL  DESCRIPTION 


The  Micro-Programmable  Data  Terminal  (MPDT)  chip  is  a 
large  scale  integrated  CMOS/SOS  circuit  designed  to  perform 
the  logic  and  digital  functions  required  to  mechanize  a 
command/response,  time  division  multiplexing  system,  as 
specified  in  MIL-STD-1553A. 

Figure  1 shows  how  the  MPDT  chip  interfaces  with  either  a 
subsystem  in  the  remote  terminal  mode  or  with  a computer  or 
controller  in  the  bus  controller  mode.  The  MPDT  chip  was 
designed  to  meet  the  requirements  of  MIL-STD-155 3A  and, 
therefore,  utilizes  the  fixed  synchronizing  patterns  defined 
therein.  However,  since  the  chip  is  programmable,  variations 
in  word  length,  field  definition,  and  system  logic  can  be 
effected  with  the  appropriately  programmed  external  ROM(s). 

In  general,  the  MPDT  circuit  is  designed  to  - 

1.  Convert  between  Manchester  and  NRZ  for  both  transmis- 
sion and  reception. 

2.  Detect  and  distinguish  between  data  and  command/status 
sync ' s . 

3.  Initialize  the  system  clock  on  sync  detection  and  gen- 
erate a clock  synchronous  with  received  data. 

4.  Respond  to  commands  (Remote  Terminal  Mode) . 

a)  Compare  terminal  address  and  proceed  if  compare 

b)  Output  subaddress/mode  and  word  count 

c)  Store  word  count 

d)  Receive  NRZ  and  transmit  Manchester  in  the  transmit 
mode;  receive  Manchester  and  output  NRZ  in  the  re- 
ceive mode 

e)  Provide  data  sync  and  parity  where  needed 

f)  Monitor  word  count  and  terminate  operation  after 
word  count  is  zero 

5.  Transmit  status  word  (Remote  Terminal  Mode), 
a)  Perform  validity  tests  on  received  data 


Figure  1.  Remote  Terminal/Controller  Configuration 


b) 

Input  function  code 

c) 

Read  terminal  address 

d) 

Assemble  and  transmit  status  word 
status  sync  and  parity 

with  command/ 

Issue  Commands  (Bus  Controller  Mode) 

a) 

At  computer  direction 

b) 

Input  command  data  from  computer 

c) 

Transmit  with  command/status  sync 

and  parity 

Monitor  Status  (Bus  Controller  Mode) 

a) 

Receive  status  words 

b) 

Independently  monitor  word  count 
(if  not  transmitting) 

and  data  validity 

c) 

Output  exceptions  to  computer 

Most  of  the  above  functions  are  controlled  by  the  ROM  pro- 
gram and  may  be  modified,  applied  to  various  data  fields, 
applied  to  different  or  additional  system  words,  or  omitted 
under  program  control.  Many  other  functions  are  also  poss- 
ible. How  the  MPDT  accomplishes  these  functions  is  dis- 
cussed in  the  subsequent  paragraphs  of  this  section. 

Figure  2 depicts  the  major  functional  blocks  of  the  MPDT 
circuit,  while  Figure  3 expands  on  the  synchronizing  and 
Manchester  decode  logic. 


2.1  Sync  and  Manchester  Decode  Logic 

This  logic  receives  complementary  data  from  the  T/R 
unit  over  two  lines-PDA  and  MDA.  It  conditions,  synchro- 
nizes and  processes  this  data:  1)  to  derive  synchronizing 

clocks,  2)  to  generate  program  interrupts  from  command/ 
status  and  data  synchronizing  pedestals,  and  3)  to  decode 
the  Manchester  encoded  signals  and  to  indicate  if  the  de- 
coded signals  are  valid  Manchester  signals. 

Figure  3 shows  a detailed  block  diagram  of  the  Sync  & 
Manchester  Decode  function.  Input  signals  PDA  and  MDA  pass 
through  a signal ' conditioning  latch,  which  prevents  the 


signals  from  being  true  simultaneously.  The  signals  are 
next  synchronized  with  the  external  clock  in  the  high  freq- 
uency data  synchronizing  logic.  Synchronization  to  the  8 MHz 
clock  allows  clocked  logic  to  be  used  in  the  remaining 
portions  of  the  chip. 

The  Transition  Detector  generates  pulses  (TCSS)  that 
are  coincident  with  changes  of  state.  A transition  pulse, 
TCSS,  is  generated  only  if  PDA  (or  MDA)  remains  high  for  at 
least  two  consecutive  cycles  of  the  8 MHz  clock.  The  TCSS 
pulse  is  conditioned  in  the  Data  Strobe  Generator  logic 
which,  in  turn,  strobes  the  received  data  (DATAR)  out  of  the 
Manch  Decode  logic.  The  Manch  Decode  logic  also  generates 
the  MANCH  signal,  which  is  a logic-low  if  the  detected  sig- 
nal is  not  a valid  Manchester  encoded  signal.  A Manchester 
encoded  bit  is  valid  if  the  state  of  PDA  before  TCSS  is  the 
complement  of  PDA  after  TCSS.  The  Transition  Detector, 

Manch  Decode,  and  the  Data  Strobe  Generator  comprise  the  bit 
detector;  a Manchester  logic  one  (zero)  is  detected  if  PDA 
is  high  (low)  and  then  low  (high)  for  at  least  two  consecu- 
tive 8 MHz  clock  times. 

The  Sync  Detector  Counter  is  a nine-bit  counter  that  is 
reset  by  the  TCSS  pulse.  If  PDA  (or  MDA)  is  high  for  at 
least  10  consecutive  8 MHz  clock  periods,  the  counter  gener- 
ates an  overflow  pulse  (OVF) . The  first  overflow  pulse  en- 
ables a gate,  allowing  the  transition  pulse,  TCSS,  to  syn- 
chronize the  Master  Clock  Counter  with  the  transition  of  the 
command/status  and/or  data  synchronizing  pedestals.  The 
overflow  pulses  clock  flipflops,  in  the  Interrupt  Generator 
Logic,  which  are  decoded  to  develop  command/status  and/or 
data  interrupts.  The  logic  also  generates  the  VSYND  signal, 
indicating  that  two  overflows  have  occurred  and  that  a valid 
synchronizing  pedestal  has  been  detected.  Upon  receipt  of 
VSYND,  the  master  clock  jam-sets  the  Slave  Clock  Counter  to 
the  same  state  as  the  master  clock  counter.  Outputs  of  the 
slave  clock  are  the  1 MHz  clock  (this  is  actually  the  1 MHz 
synchronizing  clock  CACT)  and  a 2 MHz  clock.  By  using  the 
master-slave  clock  configuration,  CACT  will  not  be  inter- 
rupted should  the  Sync  Detector  Counter  generate  a single 
spurious  overflow  pulse  due  to  system  noise.  A command/ 
status  (data)  synchronizing  signal  is  determined  to  be  valid 
if  the  signal  is  high  (low)  and  then  low  (high)  for  ten  con- 
secutive cycles  of  the  8 MHz  clock.  DDAT , which  is  PDA  de- 
layed by  two  8 MHz  clock  cycles,  is  used  to  determine  which 
synchronizing  signal  is  detected  - i.e.,  command/status  or 
data. 
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Detection  of  a command/status  sync  sets  the  program 
counter  to  hexadecimal  location  60,  sets  the  T/R  flip- 
flop  in  the  Transmitter  Control  Unit  to  the  receive  mode, 
and  resets  the  OP  flipflop  in  the  Serial  Data  Control  Unit. 

A data  sync  sets  the  program  counter  to  hexadecimal  location 
40,  sets  the  T/R  flipflop  to  the  receive  mode,  resets  the  OP 
flipflop,  and  resets  the  FI  flag  flipflop  in  the  Branch  and 
Halt  logic. 

The  Busy  Detector  senses  the  presence  of  signals  on  PDA 
and  MDA  and  generates  a signal  ( DPB)  which  is  used  in  the 
parity  and  message  error  logic  to  generate  a bus  busy  signal. 


2.2  Address  Logic  and  Program  Counter 

t 

This  function  contains  an  8-bit  Program  Counter  and  the 
associated  logic  required  to  preset  the  counter  as  deter- 
mined  by  interrupt  or  branch  inputs.  Eight  ROM  address  (ROM 
AD)  lines  are  brought  off  chip  to  an  external  ROM(s).  The 
program  counter  can  be  extended  to  any  length  by  using  the 
JUMP  8 and  CAROI  lines,  with  the  addition  of  an  external 
counter.  The  external  counter  would  constitute  the  least 
significant  bits  of  the  extended  counter.  The  CAROI  line 
would  carry  the  overflow  signal  from  the  external  counter  to 
the  chip  counter  and  the  JUMP  8 line  would  be  used  to  reset 
the  external  counter.  The  JUMP  8 line  is  set  to  a logic 
high  by  either  an  interrupt  or  by  an  absolute  branch 
(ABRANCH) . 

An  interrupt  or  a branch  signal  presets  the  program 
counter  to  a given  state.  The  counter  then  sequences 
through  its  instruction  set  (1  bit  at  a time  with  clock  rate 
determined  by  CACT)  until  it  is  set  to  a new  location  by  a 
branch  instruction  or  another  interrupt. 


2.3  Instruction  Register  and  Decoder 

The  MPDT  derives  an  8-bit  instruction  from  two  4-bit 
words,  sequentially  read  over  the  four  ROM  data  (RD)  lines 
( RDO , . . . RD3 ) . The  derived  system  clock  (CACT)  is  used  to 
strobe  the  two  4-bit  words  from  the  ROM  memory (s) . On  the 
first  half  cycle  of  CACT,  the  first  4-bit  word,  called  the 
most  significant  position  word  (MSPW)  is  loaded  into  the 
instruction  register.  On  the  second  half  cycle  the  4-bit 
least  significant  position  word  (LSPW)  and  the  MSPW  are 
clocked  into  the  decode  logic  to  form  the  8-bit  instruction. 
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2.4  Branch  and  Halt  Logic 

This  logic  contains  the  Halt,  FI,  F2  and  B flipflops. 
The  output  of  the  B flipflop  is  brought  off  chip  for  use  in 
the  subsystem.  The  primary  purpose  of  this  flipflop  is  to 
store  the  transmit/receive  bit  in  the  command  word.  How- 
ever, any  data  bit  can  be  stored  as  programmed.  The  bit 
stored  is  selected  by  the  instructions  HB  and  HBP . 

The  two  flag  flipflops,  FI  and  F2,  are  used  to  develop 
branch  and  halt  conditions.  Absolute  branches  will  occur 
when  the  appropriate  flipflop  is  set  and  a BRF 1 or  BRF2 
instruction  is  executed.  These  flipflops  are  controlled  by 
the  FLG  and  EDI  instructions.  A conditional  halt,  set, 
reset  or  no  action  (NO-OB)  is  initiated  in  accordance  with 
the  contents  of  the  LSPW  of  the  EDI  or  FLG  instruction. 

The  power  on  reset  (POR)  line  sets,  and  holds  the  Halt 
flipflop  set,  whenever  the  line  is  low.  POR  also  resets  FI 
and  F2. 

The  SENSE  input  is  used  in  conjunction  with  the  BRS 
instruction.  The  SENSE  line  provides  a means  of  causing 
program  branches  from  external  stimulus.  The  sense  line  is 
employed  when  the  MPDT  is  functioning  in  the  bus  controller 
mode. 


2.5  Word  Counter 

The  word  counter  contains  the  logic  to  serially  load 
a five-bit  counter.  Loading  of  the  counter  is  initiated  by 
the  instruction  load  data  word  counter  (LDWC) . The  LDWC 
instruction  sets  the  Word  Count  (WC)  flipflop  causing  the 
received  data  to  be  loaded  into  the  counter.  A subsequent 
LDWC  instruction  will  toggle  the  WC  flipflop  and  disable  the 
counting  action.  To  load  a five-bit  word  into  the  counter, 
the  instruction  sequence  could  be  LDWC,  No-Op,  No-OP,  No-Op, 
LDWC.  Other  instructions  may  be  substituded  for  the  N-Op's 
if  needed,  but  there  must  be  three  and  no  halt  may  occur. 

The  counter  is  decremented  by  the  decrement  data  word 
counter  (DDWC)  instruction.  The  word  counter  is  decremented 
each  time  a DDWC  instruction  is  executed. 


2.6  Control  Output  Logic 

Four  control  output  (CO)  lines  are  brought  off  chip 
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providing  the  subsystem  with  a 4-bit  control  word.  This  4- 
bit  control  word.  This  4-bit  word  is  used  to  transmit  the 
status  or  state  of  the  DT  chip  to  the  subsystem,  and  it  can 
be  used  to  control  external  functions  using  ROM  data. 

Status  information  transmitted  might  include,  for  example, 
end  of  receive  command,  begin  receive  command,  end  transmit 
data  word,  and  so  on.  When  instructions  THI,  TLO,  PTY , SCO, 
SCOR,  and  TME  are  decoded,  the  control  output  register  is 
loaded  with  the  LSPW  from  the  instruction  ROM.  When  the 
ICOD  instruction  is  decoded,  and  the  data  is  a logical  one, 
the  LSB  of  the  control  output  word  is  inverted.  This 
instruction  is  used  to  simplify  instructions  involving 
branch  on  data  programs. 


2.7  Parity  and  Message  Error 

This  logic  contains  the  parity  generator  and  comparison 
circuits,  the  message  error  (ME),  and  the  end  of  word  (EW) 
flipflops.  In  the  receive  mode,  parity  is  locally  generated 
from  the  data  and  compared  with  the  parity  bit  of  the 
received  word,  on  execution  of  the  parity  (PTY)  instruction. 
If  the  parity  bits  do  not  compare,  the  ME  flipflop  is  set. 

In  the  transmit  mode,  a parity  signal  is  generated  and  a 
parity  bit  is  inserted  in  the  transmitted  data  word  on 
execution  of  the  PTY  instruction. 

The  ME  flipflop  is  set  only  in  the  receive  mode,  when 
not  in  the  halt  mode,  and  when  any  of  the  following  occur: 

1)  the  locally  generated  parity  bit  is  not  equal  to 
the  received  parity  bit  on  PTY  instruction, 

2)  data  is  received  and  the  EW  flipflop  is  set, 

3)  a set  message  error  (SME)  instruction  is  executed, 

4)  an  invalid  Manchester  signal  occurs. 

An  invalid  Manchester  signal  includes  synchronizing 
signals  if  those  signals  do  not  result  in  interrupts. 

The  busy  line  indicates  the  detection  of  data  on  the 
bus.  The  busy  line  will  be  high  if  there  has  been  data  on 
the  bus  in  the  last  two  bit  times;  otherwise,  the  line  will 
be  low. 


330 


2.8  Serial  Data  Control 


1 


This  logic  controls  the  tri-state  output  circuit  (see 
Figure  5)  which  drives  the  bidirectional  data  line  (DATTT) . 
Data  is  transmitted  (see  Section  3)  to  the  subsystem  when 
the  output  (OP)  flipflop  is  set.  When  OP  is  reset,  the 
output  driver  is  disabled.  The  state  of  the  OP  flipflop  is 
controlled  by  instructions,  interrupts  and  by  the  state  of 
the  OPM  flipflop.  If  0PM  is  in  a reset  state,  the  OP  flip- 
flop  is  set  by  an  SCO  instruction  and  is  reset  by  an  SCOR 
instruction.  OP  cannot  be  set  if  OPM  is  in  a set  state,  but 
if  OP  is  set  before  OPM  is  set,  it  will  stay  set  until  nor- 
mal OP  reset  conditions  occur.  OP  is  reset  by  any  interrupt 
and  by  a PTY  instruction. 

In  the  transmit  mode,  the  signal  XON  disables  the  out- 
put circuit.  Data  to  the  chip  from  the  subsystem  is  routed 
through  the  input  circuit  as  discussed  in  Section  3.2. 


2.9  Terminal  Address  Logic 

Five  terminal  address  lines  (TAO  - TA4)  are  brought 
off  chip  allowing  for  identification  of  up  to  32  data  termi- 
nals. In  the  receive  mode,  the  terminal  address  logic  com- 
pares the  states  of  the  five  strapped  address  lines  with 
the  decoded  serial  Manchester  data  (DATAR) . The  comparison 
is  done,  one  bit  at  a time,  whenever  a BNTA  instruction  is 
encountered.  If  the  addresses  compare,  the  program  contin- 
ues. If  they  do  not  compare,  the  terminal  address  logic 
sends  a signal  to  the  Branch  and  Halt  Logic  causing  the  MPDT 
to  branch  to  another  subroutine. 

In  the  transmit  mode,  the  terminal  address  logic  gen- 
erates the  bit  patterns  for  transmitting  the  terminal 
address,  via  the  Transmitter  Control  logic.  Transmission 
of  the  terminal  address  is  initiated  by  the  transmit  termi- 
nal address  (TTA)  instruction.  The  TTA  instruction  tog- 
gles the  TA  flipflop.  When  the  TA  flipflop  is  set,  the 
terminal  address  is  transmitted  as  described  under  the  TTA 
instruction . 


2.10  Transmitter  Control 

This  logic  formats  and  sequences  the  data  to  be  encoded 
and  transmitted.  Synchronizing  pedestals,  terminal 
addresses,  message  errors,  data,  and  parity  are  all 
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sequenced  through  the  transmitter  control  logic. 

The  T/R  flipflop  is  set  (transmit  or  T mode)  by  THI 
and  TLO  instructions.  It  is  reset  (receive  or  R mode)  by 
the  PTY  instruction  or  by  any  interrupt.  In  the  T mode  data 
is  sequenced  one  bit  at  a time  and  transmitted.  A change  to 
the  T mode  is  not  allowed  if  the  bus  is  busy  or  has  been  in 
the  last  two  bit  times  (i.e.,  if  the  busy  flipflop  is  set). 

If  a change  to  the  T mode  is  attempted  while  the  bus  is  busy, 
the  system  clock,  CACT,  is  halted  until  the  busy  line 
returns  to  a logic  low. 


2.11  Manchester  Encoder 

Data  originating  in  the  transmitter  control  unit  is 
converted  to  Manchester  encoded  data  in  the  Manchester 
encoded  unit.  Two  complementary  lines  (MOPI  and  MOPI)  are 
brought  off  chip. 
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3 . INTERFACE  DATA 


Electrical 


Pin-out  and  electrical  output  signals  are  TTL 
compatible.  The  output  lines  will  drive  50  pf  and  one  low 
power  Schottky  load,  at  a serial  bit  rate  of  at  least  1 MHz. 


Table  1 Electrical  Specifications 

Min.  Nom.  Max.  Unit 


Supply  Voltage  (VDD) 
Supply  Voltage  (Vcc) 

Low  Level  Input  Voltage 
High  Level  Output  Voltage 
Low  Level  Output  Voltage 
High  Level  Input  Voltage 
Low  Level  Output  Current 
High  Level  Output  Current 
Low  Level  Input  Current 
High  Level  Input  Current 
Output  Load  Capacity 
Output  Rise/Fall  Time 
Clock  Frequency 


+9 

+10 

+11 

V 

+4.75 

+5 

+5.25 

V 

0.4 

0.6 

0.8 

V 

Vcc 

V 

0.4 

V 

4 

5 

7 

V 

-400 

UA 

100 

uA 

-175 

uA 

Nil 

P A 

50 

Pf 

30 

nsec 

8* 

MHz 

*For  a 1 MHz  data  rate 


Subsystem  Data 


All  data  is  transferred  serially  between  the  MPDT  and 
the  subsystem  on  the  bidirectional  port  DATTT.  The  input 
and  output  circuits  are  TTL  compatible  as  shown  in  Figures  4 
and  5.  Control  of  the  tri-state  output  circuit  is  described 
in  Section  2. 


Figure  4-a  Basic  TTL  Compatible  Input  Circuit 


ROM 


The  instruction  word  is  composed  of  two  4-bits  word 
which  are  read  sequentially  from  the  program  ROM  over  lines 
RDO  . ...RD1.  The  program  ROM(s)  is  addressed  with  eight 
address  lines  RAO  . . . . RA7 , and  with  the  system  clock  CACT. 
Each  instruction  occupies  two  4-bit  words  in  sequence.  The 
first  word  of  each  instruction  (most  significant  position 
word,  MSPW)  occupies  an  even  numbered  memory  location.  The 
MSPW  is  read  from  memory  during  the  first  half  cycle  of  the 
system  clock  CACT,  and  loaded  into  the  instruction  register. 
The  least  significant  position  word  (LSPW)  is  read  from 
memory  on  the  second  half  cycle  of  CACT.  ROM  size  (number 
of  4-bit  words)  is  variable  and  unlimited  as  is  the  number 
of  bits  in  an  instruction  address.  Instruction  address  bits 
are  defined  as 

Z YYYY  XXXX  W 

where  W is  LSB  of  the  address.  The  LSB  is  CACT,  with  W = 0 
during  first  half  cycle  for  the  even  memory  location  of 
MSPW,  and  with  W = 1 during  the  second  half  cycle  for  the 
address  of  LSPW.  The  number  of  bits  in  field  XXXX  is  varia- 
ble and  unlimited;  four  bits  are  sufficient  for  MIL-STD- 
1553A.  More  would  be  needed  for  a data  format  with  words 
longer  than  16  bits.  An  external  extension  to  the  program 
counter  is  needed  if  this  field  is  longer  than  four  bits. 
Field  YYYY  is  always  four  bits.  They  are  the  four  bits 
specified  in  the  branch  instructions  and  by  interrupts. 

Z is  a page  bit(s).  The  number  is  variable  with  a minimum 
of  zero.  For  a MIL-STD-1553A  remote  terminal  or  a bus 
controller,  none  is  required.  For  a combination  MIL-STD- 
1553A  remote  terminal/bus  controller  one  bit  is  required. 

In  this  case,  the  bit  is  controlled  from  an  external  source, 
(it  switches  the  MPDT  between  remote  terminal  and  bus 
controller) . However,  outputs  from  control  lines 
(COO  ...C03)  could  be  used  for  self  control. 
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4.  INSTRUCTIONS,  INTERRUPTS,  MODES  AND  FLIPFLOPS 


4 . 1 Programming  Features 


The  data  terminal  is  programmed  on  a one-bit  (received 
or  transmitted)  per  instruction  basis. 

For  example,  the  following  sequence  of  instructions 
will  transmit  a four  bit  data  word: 

Sets  transmit  (T)  mode,  transmits  a data 
sync,  and  sets  the  CO's  to  316  (0011), 
which  notifies  the  subsystem  of  the 
impending  requirement  for  it  to  input 
data . 

Inputs  and  transmits  four  bits  (one  for 
each  instruction;  these  are  No-Ops,  but 
any  could  be  used  which  does  not  inter- 
fere with  the  data  operation) . For  a 
longer  data  field  more  instructions  are 
used. 

Transmits  an  odd  parity  bit;  sets  the 
CO's  to  216  (0010),  which  notifies  the 
subsystem  that  data  entry  from  it  is 
complete . 

Halts;  awaits  an  interrupt  to  begin 
action.  " 

Instructions  are  composed  of  two  4-bit  words.  Instruc- 
tions are  read  out  of  the  ROM  as  follows:  On  the  first  half 

cycle  of  the  clock  (CACT) , the  most  significant  position 
word  (MSPW)  is  clocked  into  a 4-bit  instruction  holding 
register.  A 4-bit  least  significant  position  word  (LSPW) 
is  next  clocked  into  the  instruction  decoding  logic  and  on 
the  second  half  of  the  clock  cycle,  the  two  words,  MSPW  and 
LSPW,  are  decoded  to  form  the  instruction. 

There  are  both  Sequence  and  Branch  instructions.  Of 
the  23  Sequence  instructions,  seven  have  provision  for 
control  words  in  the  LSPW.  The  instructions  are  described 
in  subsequent  paragraphs,  and  are  summarized  in  Table  2. 


TLO  316  ) 
TZRO 
THI  316  ) 


FLG  F ) 
FLG  F ( 
FLG  F ( 
FLG  F ) 


PTY  2 j 6 


HLT 


Table  2.  Instructions 


MSPW  (IR) 


LSPW  (RD) 


Mnemonic 


Sequence  Instruction 


0 0 0 0 


0 0 0 0 
0 0 0 1 
0 0 10 
0 0 11 
0 10  0 
0 10  1 
n i i n 


0 111 
10  0 0 
10  0 1 
10  10 
10  11 


HLT 

TTA 

TZRO 

TONE 

HB 

HBP 

RB 

HNB 

RME 

SME 

LDWC 

DDWC 

F20PM 

DDI 

ICOD 

HME 


Absolute  Branch 
Instructions 


0 0 0 1 

(A  A A A ) 

BR 

0 0 10 

/ O D 

BRS 

0 0 11 

BRCNZ 

0 10  0 

BRF1 

0 10  1 

BRF2 

Relative  Branch 
Instructions 


0 110 


10  0 0 


<A7A6A5V 


BRD 

BRNB 

BNTA 


Sequence  Instructions 
With  Control  Word 


10  0 1 
10  10 


110  1 


CO'S 

PTY 

f 

THI 

TCO 

if 

SCO 

( CO's  ) 

SCOR 

CO's/flag  control 

TME/EDI* 

flag  control 

FLG 

*TME  if  in  transmit  mode,  EDI  in  receive  mode 


4.1  Sequence  Instructions 


When  a Sequence  instruction  is  executed,  the  program 
counter  sequences  to  the  next  location.  Branch  instructions, 
if  a branch  occurs,  cause  the  program  counter  to  jump  to  a 
location  out  of  sequence.  The  following  is  a list  of 
sequence  instructions;  the  instructions  are  listed  with 
their  mnemonic  names  followed  by  a hexadecimal  listing  of 
(MSPW  LSPW) : 

HLT  (00)  Halt.  Stops  transmission,  reception, 

I/O  and  instruction  execution.  Stops 
system  clock  CACT  and  resets  T/R 
flipflop.  Recovery  is  by  interrupt. 

T or  R mode. 

TTA  (01)  Transmit  Terminal  Address.  Effective 

in  T mode  only.  It  starts  trans- 
mission of  terminal  address,  which 
continues  until  another  TTA  instruc- 
tion is  executed.  The  instruction 
toggles  the  TA  flipflop.  When  TA  is 
set  or  this  instruction  is  being 
executed,  bit  J (0  < J < 4)  of  ter- 
minal address  is  transmitted  and  J is 
incremented  by  1.  J is  reset  to  zero 
by  the  combination  of  a TA  reset  and 
any  instruction  other  than  TTA  or 
BNTA.  Bit  J = 0 is  MSB. 


TZRO  (02) 


Transmit  a zero.  Effective  in  T mode 
only. 


TONE  (03) 


Transmit  a one.  Efective  in  T mode 
only. 


HB  (04) 
HBP  (05) 


RB  (06) 
HNB  (07) 


Hold  Bit.  Store  the  received  or 
transmitted  bit  in  the  B flipflop. 

Hold  Bit  Past.  Store  the  preceding 
received  or  transmitted  bit  in  the 
B flipflop. 

Reset  B flipflop.  T or  R mode. 

Halt  if  not  B.  Halt  if  B is  logic 
zero.  T or  R mode. 


RME  (08) 

SME  (09) 
LDWC  (0  A) 


DDWC  (0  B) 

F20PM  (0  C) 
DDI  (0  D) 

ICOD  (0  E) 

HME  (0  F) 
PTY  (9  X) 

THI  (A  X) 


Reset  message  error  flipflop.  T or  R 
mode . 

Set  message  error  flipflop  R mode  only. 

Load  data  word  counter.  Toggle  WC 
flipflop.  If  the  WC  flipflop  is  set, 
shifts  word  counter  and  loads  the 
current  data  bit  into  the  low  order 
bit  position  of  the  word  counter.  The 
high  order  bit  of  word  counter  is  lost. 
T or  R mode . 

Decrement  data  word  counter.  Decre- 
ments the  word  counter  by  one.  T or 
R mode. 

Transfer  the  state  of  F2  flipflop  to 
OPM  flipflop  T or  R mode. 

Disable  data  interrupt.  A data  sync 
will  not  result  in  an  interrupt  if  it 
ends  later  than  one  bit  time  preceding 
this  instruction.  R mode  only. 

Invert  control  output  data.  Inverts 
the  control  output  line  COO  if  the 
data  is  a logic  one.  T or  R mode. 

Halt  message  error.  Halts  DT  if  ME 
flipflop  is  set.  T or  R mode. 

Parity.  In  the  T mode,  this  instruc- 
tion transmits  a parity  bit  based  on 
all  data  since  the  last  sync.  In  the 
R mode,  this  instruction  checks  parity 
based  on  all  data  since  last  sync 
interrupt.  If  no  parity  match,  it 
sets  ME  flipflop,  otherwise  it  does 
not  change  ME.  Resets  OP  flipflop. 

LSPW  X is  loaded  into  the  CO  register. 
OP  reset  and  other  functions  effective 
on  current  bit. 

Transmit  high.  Transmits  a one  bit 
time  high  signal  and  sets  the  T/R 
flipflop.  LSPW  X is  loaded  into  the 
CO  register. 
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TLO  (B  X) 


SCO  (C  X) 


SCOR  (D  X) 


TME  (E  X) 
EDI  (E  X) 


FLG  (F  X) 


Transmit  low.  Transmits  a one  bit 
time  low  signal  and  set  the  T/R  flip- 
flop.  LSPW  X is  loaded  into  the  CO 
register.  The  sequence  of  instruc- 
tions THI,  TONE,  TLO  sends  a command 
or  status  sync.  The  sequence  of 
instrunctions  TLO,  TZRO,  THI  sends  a 
data  sync. 

Set  control  output.  Loads  LSPW  X into 
the  CO  register  and  sets  OP  flipflop, 
effective  on  current  bit  time.  T or 
R mode. 

Set  control  output  reset.  Resets  the 
OP  flipflop  disabling  DATTT  output  and 
loads  LSPW  X into  the  CO  register.  OP 
reset  is  effective  on  following  bit 
time.  R mode  only. 

Transmit  message  error.  Transmits  the 
ME  bit.  LSPW  X is  loaded  into  the  CO 
register.  T mode  only. 

Enable  data  interrupt.  In  R mode,  a 
data  sync  will  result  in  an  interrupt 
if,  and  only  if,  it  begins  not  more 
than  two  bit  times  before  EDI,  where 
data  interrupt  was  previously  disabled. 
LSPW  X controls  FI  and  F2  flags  as 
discussed  in  Section  2.  R mode  only. 

Flag.  Controls  and  provides  condi- 
tional halt  option  on  flags  FI  and  F2. 
LSPW  X controls  FI  and  F2  as  discussed 
in  Section  2.  FLG  F ( F F)  is  the  no 
operation  instruction.  T or  R mode. 


Branch  Instructions 

When  a branch  instruction  is  decoded,  the  program 
counter  will  be  set  to  a new  state,  if  it  is  an  uncondi- 
tional branch  or  if  the  condition(s)  of  a conditional  branch 
are  met.  The  new  state  depends  upon  whether  the  instruction 
is  an  absolute  branch  or  a relative  branch. 
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Absolute  branches  set  the  four  high  order  bits  of  the 
program  counter  to  X where  X is  the  LSPW  of  the  branch 
instruction.  The  low  order  bits  of  the  program  counter 
are  set  to  zero.  The  following  are  absolute  branch  instruc- 
tions . 


BR  (1  X)  Branch  unconditionally.  Control 

transfer  always  occurs  to  location  XO. 
T or  R mode. 


BRS  (2  X)  Branch  on  Sense.  Branches  to  location 

XO  if  sense  line  is  high.  T or  R 
mode . 


BRCNZ  (3  X) 


Branch  if  word  count  is  not  zero.  T 
or  R mode. 


BRF1  (4  X) 


Branch  if  FI  flipflop  is  set.  T or 
R mode. 


BRF2  (5  X) 


Branch  if  F2  flipflop  is  set.  T or 
R mode . 


Relative  branches  set  the  state  of  the  program  counter 
to  location  XY  where  X is  the  LSPW  of  the  branch  instruction 
and  Y is  value  of  the  lower  order  bits  of  the  program 
counter  for  the  next  instruction  in  sequence.  The  following 
are  relative  branch  instructions. 


BRD  (6  X) 


Branch  on  data.  Branch  if  data  is  a 
logic  one.  T or  R mode. 


BRNB  (7  X) 


Branch  if  B flipflop  is  reset.  T or 
R mode . 


BNTA  (8  X)  Branch  on  not  terminal  address.  In 

the  R mode,  this  instruction  compares 
bit  J (0  5 J 54)  of  the  terminal 
address  with  received  bit.  Branch 
occurs  if  no  match,  but  proceeds  to 
next  instruction  if  a match  occurs. 
Branch  also  occurs  if  received  bit 
is  invalid  Manchester.  The  instruc- 
tion increments  J by  one,  and  all 
other  instructions  except  TTA  reset  J 
to  zero.  Bit  j = 0 is  MSB  of  terminal 
address.  R mode  only. 


MIL- STD- 155 3 A SAMPLE  PROGRAMS 


This  section  illustrates  some  sample  programs  for  the 
remote  terminal  (RT)  mode.  The  programs  demonstrate  how 
the  MPDT  would  be  programmed  to  accommodate  MIL-STD-1553A 
word  and  message  formats.  Fig.  6 shows  the  flow  diagram  for 
a remote  terminal  in  the  receive  command  mode.  Table  3 
explains  the  instruction  sequence.  Fig.  7 shows  the  flow 
diagram  for  a remote  terminal  in  the  receive  data  mode.  Table 
4 explains  the  instruction  sequence.  Programs  for  other  modes, 
including  the  bus  controller  are  described  in  Rockwell  Report 
T-76-917/201.  Abbreviations  used  in  the  programs  are  consis- 
tent with  MIL-STD-1553A.  TA,  for  example,  is  terminal  address, 
S/A  is  subaddress  mode,  ME  is  message  error  and  T/F  is  terminal 
flag.  The  three  basic  bus  communications  illustrated  are  BC  to 
RT,  RT  to  BC,  and  RTl  to  RT2 . 


Instruction  addresses  are  designated  by  hexidecimal 
characters  both  on  the  flow  diagrams  and  on  the  program 
listings.  The  following  control  outputs  are  also  used  in 
the  sample  programs: 


LSPW  (Hexidecimal) 


Action 


0 

1 

2 

3 

4 

5 

6 

7 

8 
9 

10 

11 

12 

13 

14 


End  Receive  Command  (RT) 

Begin  Receive  Command  (RT) 

End  Transmit  Data  Word  (RT) 

Begin  Transmit  Data  Word  (RT) 

End  Transmit  Status  Word  (RT) 
Begin  Transmit  Status  Word  (RT) 
"No  Data"  Exception  (BC) 

"No  Status"  Exception  (BC) 

End  Receive  Data  Word  (RT) 

Begin  Receive  Data  Word  (RT) 
Message  Error  Exception  (BC) 
Status  Code  or  T/F  Exception  (BC) 
Data  Missing  (BC) 

"Terminal  Status"  Exception  (BC) 
Data  Operation  Complete  (BC) 


3 


Table  3 RT  RECEIVE  COMMAND  INSTRUCTIONS 


IA 

I 

RT  - Receive  Command 

- 

- 

Command  Sync  Interrupt 

8016 

BNTA  0lg 

\ 

81 

BNTA  0 

1 

82 

BNTA  0 

\ Branch  if  the  incoming  data  is  not 
[a  command  for  this  terminal. 

83 

BNTA  0 

| 

84 

BNTA  0 

' 

85 

HB 

86 

SCO  1 

Begin  output  of  SA/Mode;  Set  CO's  to 
begin  receive  command. 

87 

FLG  F 

) 

88 

FLG  F 

/Complete  reception  and  output  of 
1 SA/Mode . 

89 

FLG  F 

) 

8A 

SCOR  1 

Suppress  output  of  DWC 

8B 

LDWC 

\ 

8C 

FLG  F 

1 

8D 

FLG  F 

/Load  data  word  count 

8E 

FLG  F 

1 

8F 

LDWC 

) 

90 

PTY  0 

Check  parity;  Set  CO's  to  end  receive 
command . 

I 
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Table  3 (cont) 


IA 

i 

RT  - Receive  Command 

91 

BRNB  6 

Branch  if  data  is  to  be  received;  con- 
tinue if  it  is  to  be  transmitted. 

92 

HME 

Suppress  transmission  if  error  on 
command  reception. 

93 

BR  A 

Branch  to  Transmit  Status  Routine 
(Loc  AO) 

62 

EDI  7 

[Entry  point  from  branch  in  Loc.  91] 
Enable  data  sync  interrupt  and  set  FI. 

63 

DDI 

Disable  data  sync  interrupt 

64 

FLG  B 

Reset  FI 

65 

HLT 

Anticipated  data  did  not  appear 

01 

FLG  F 

j 

04 

FLG  F 

jEntry  points  for  branches  in  80-84 

05 

BRD  1 

Branch  if  the  M/E  or  T/R  Bit  = 1 

06 

FLG  8 

Reset  Fl  and  Halt  if  F2  is  reset  (F2 
set  means  this  interrupt  occurred  in 
the  time  window  for  a status  from  an 
RT  which  has  been  commanded  to  transmit 
to  this  one) 

07 

FLG  E 

Reset  F2 

08 

FLG  F 

/Time  to  data  sync  window 

11 

FLG  F 

I 

12 

EDI  F 

j Enable  data  sync  interrupt  for  the 
[time  window  in  which  data  from 
) another  RT  to  this  one  will  appear. 

14 



HLT 

Halt  - data  was  not  there 

5 


Table  3 (cont) 


IA 

I 

RT  - Receive  Command 

16 

FLG  2 

Enter  by  branch  from  location  05 
Reset  F2;  Halt  if  FI  is  reset  (Fl  set 

17 

FLG  B 

means  the  sync  for  the  command  now 
being  received  occurred  immediately 
after  a receive  command  to  this  RT  and 
thus  that  this  is  probably  a command 
for  another  RT  to  transmit  to  this  RT) . 

Reset  Fl 

18 

FLG  F 

| 

IF 

FLG  F 

jTime  to  end  of  word;  no  output 

20 

PTY  0 

Check  parity  (to  set  EW  and  prevent 

21 

FLG  F 

setting  ME  in  the  intermessage  gap) ; 
leave  CO's  at  End  Receive  Command 

) 

22 

FLG  F 

\ Time  to  beginning  to  status  sync 

23 

FLG  G 

1 window 

24 

FLG  D 

Set  F2  (begin  status  sync  window) 

25 

FLG  F 

) 

26 

FLG  F 

>Time  to  end  of  status  sync  window 

27 

FLG  F 

1 

28 

FLG  E 

Reset  F2  (status  sync  not  received) 

29 

HLT 

Operation  terminated;  status  word  did 

not  arrive  in  its  window 

DATA  SYNC 


SET 

CONTROL 

OUTPUTS 


RESET  FI; 
DECREMENT 
WORD 
COUNTER 


OUTPUT 

DATA 


CHECK  PARITY 


COUNT  = 0? 
(BCNZ)  _ 


ENABLE  DATA 
SYNC  INTERRUPT 


/ BR  TO  N 
TRANSMIT  STATUS 
SUBROUTINE 
v (AO)  y 


DISABLE  DATA 
SYNC  INTERRUPT 


WAIT  UNTIL 
LINE  IS  NOT  BUSY 


/ BR  TO  \ 
TRANSMIT  STATUS 
SUBROUTINE 
\ (AO)  


Table  4 RT  RECEIVE  DATA  INSTRUCTIONS 


I 

RT  - Receive  Data 

- 

Data  sync  interrupt  (resets  Fl) 

401fi 

SCO  916 

Begin  output;  set  CO's  for  begin  data 

ID 

word  (1001) 

41 

DDWC 

Decrement  DWC 

42 

FLG  F 

1 No  Ops  for  balance  of  reception 

4F 

FLG  F 

| and  output 

50 

PTY  8 

Check  parity;  set  CO's  for  end  data 
word  (1000) 

51 

BCNZ  3 

Branch  to  location  30^g  if  more  data 
expected 

52 

BR  A 

If  no  more  data  branch  to  location 
A0  (transmit  status) 

30 

EDI  F 

Enable  data  sync  interrupt  for  its 
time  window 

31 

DDI 

Disable  it  at  close  of  its  time 
window 

32 

SME 

Set  ME  (Because  data  is  missing) 

33 

BR  A 

Branch  to  A0  (transmit  status) 

■ 

USE  OF  STANDARD  MODULES  FOR  AIRBORNE 
MULTIPLEXING  APPLICATIONS 
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USE  OF  STANDARD  MODULES  FOR  AIRBORNE 
MULTIPLEXING  APPLICATIONS 

J.  W.  McCuen 

Hughes  Aircraft  Company 
Microelectronic  Products  Division 
Newport  Beach,  California 


Microelectronic  technology  and  multiplex  standards  have 
advanced  to  a level  where  standard  LSI/Hybrid  modules  can 
be  fabricated  for  use  as  the  Front  End  element  of  MIL-STD- 
1553A  Terminals.  This  paper  describes  Hughes  Aircraft 
Company's  approach  in  the  development  of  Front  End  Modules 
and  associated  Signal  Conditioning  Modules  which  comprise 
an  airborne  Multiplex  Terminal.  The  Front  End  Module  can 
be  employed  singularly  or  in  a multiple  configuration  within 
a terminal  to  meet  system  redundancy  requirements.  A one 
module  configuration  is  used  with  a single  bus  MUX  system 
and  a two  module  configuration  is  used  with  a dual  bus 
system.  The  Front  End  Module  contains  all  necessary  control 
and  logic  functions  for  terminal  operation;  thus  it  needs 
no  support  from  the  subsystem.  This  is  most  important  in 
an  airframe/electrical  multiplex  (EMUX)  system  application 
where  the  terminal  does  not  interface  with  any  one 
particular  subsystem  but  with  many  subsystems.  The 
versatility  of  the  Front  End  Module  allows  it  to  be  used 
with  all  1553A  type  multiplex  applications,  include  EMUX, 
SOSTEL,  AMUX,  CITS  MUX,  DAIS,  IACS , etc.  Significant 
reduction  in  size  and  cost  of  Front  End  Modules  has 
resulted  from  the  use  of  LSI/Hybrid  devices,  allowing  the 
MUX  terminal  to  be  easily  integrated  into  user  system. 
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INTRODUCTION 


The  day  of  the  low  cost,  standard,  fully  LSI/Hybrid 
Multiplex  Terminal  will  soon  be  here.  Three  things  are 
presently  occurring  to  make  this  a reality. 

1.  Standardization  of  MUX  functions. 

2.  Advancements  in  microcircuit  device  technology. 

3.  Sizeable  hardware  orders  to  defray  the  LSI/Hybrid 
development  costs. 

In  light  of  these  events,  Hughes  is  developing  a LSI/Hybrid 
Front  End  Module  which  has  a common  and  standard  application 
to  all  types  of  MIL-STD-1 553A  Remote  Terminals  (RT) , providing 
RT  service  to  both  avionic  type  systems  and  airframe  and 
electrical  type  systems.  The  module  will  be  interchangeable 
between  the  two  types  of  application. 

The  Remote  Terminal,  as  defined  by  MIL-STD-1553A,  is 
"that  electronics  necessary  to  interface  the  MUX  bus(es) 
with  the  subsystem  and  the  subsystem  with  the  bus(es)". 

That  definition  is  only  adequate  if  the  configuration  of 
various  type  subsystems  and  the  data  transfer  function 
required  of  the  subsystem  are  generalized.  The  RT  required 
to  service  an  airborne  radar  system  (avionic  subsystem) 
could  consist  of  nothing  more  than  a single  Printed  Circuit 
Board  (PCB)  containing  a multiplex  Front  End  Module (s)  and 
an  Input/Output  (I/O)  LSI  device  to  effect  bidirectional 
data  transfer  with  the  radar  system.  Figure  1 depicts 
such  a RT  showing  dual  Front  End  Modules  for  operation 
with  redundant  MUX  buses.  Such  a RT  would  be  a plug-in 
unit  contained  in  a typical  avionics  line  replaceable  unit 
(LRU).  Design  of  the  RT  would  resemble  other  PCB ' s in  the 
avionics  LRU. 

A Remote  Terminal  required  to  service  an  airframe/ 
electrical  type  system(s)  would  have  a much  different 
appearance.  It  would  be  a stand-alone  LRU  requiring  its 
own  power  supply.  It  would  contain  a Front  End  PCB  similar 
to  that  shown  in  Figure  1 and  Signal  Conditioning  PCB ' s 
like  those  shown  in  Figure  2.  The  quantity  of  Signal 
Conditioning  PCB's  is  determined  by  the  number  of  I/O 
signal  functions  to  be  handled  by  the  RT . The  signal 
functions  could  encompass  the  whole  gamut  of  signal  types, 
such  as  bilevel  discretes,  analog,  synchro,  and  both 
parallel  and  serial  digital  data.  Generally,  when 
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MIL-STD-1553A  MULTIPLEX  TERMINAL 
(Showing  Dual  Redundant  Front  End  Modules) 

FIGURE  1 


involved  with  avionic  type  MUX  systems  (AMUX) , Remote 
Terminals  of  the  type  depicted  by  Figure  1 are  employed. 

Remote  Terminals  which  would  service  airframe/electrical 
(EMUX)  type  systems  would  be  comprised  of  PCB ' s depicted 
by  both  Figures  1 and  2. 

REMOTE  TERMINALS  EMPLOYING  FRONT  END  MODULES 

The  common  functional  element  of  both  the  AMUX  and 
EMUX  type  Remote  Terminal  is  that  section  of  circuitry 
previously  referred  to  as  the  Front  End,  which  is  the  basic 
subject  of  this  paper.  Figure  1 shows  two  Front  End  Modules 
mounted  on  a PCB  to  provide  total  dual  redundant  RT  operation. 
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SICNA1.  CONDITIONING  CARD  - EMUX  TYPE 
(Showing  A/D,  D/A,  and  Discrete  I/O  Modules) 

FIGURE  2 


Figure  3 is  the  block  diagram  of  the  Front  End  Module  that 
Hughes  (Microelectronic  Products  Division)  is  developing 
for  various  systems  applications  requiring  MIL-STD-1553A 
hardware.  Unlike  other  MUX  modules,  boards  and  devices 
appearing  in  the  marketplace,  the  Hughes  Front  End  Module 
contains  all  the  circuitry  to  function  as  a stand-alone 
MIL-STD-1553A  Remot“  Terminal. 


What  is  significant  about  the  Front  End  Module  is 
that  it  provides  a standard  interface  between  the  Front 
End  and  the  Signal  Conditioning  Section  that  can  work 
directly  with  any  type  of  AMUX  or  EMUX  type  air  vehicle 
system  without  support  from  the  subsystem  or  any  additional 
circuitry.  Figure  4 depicts  the  operational  interface  with 


BLOCK  DIAGRAM  OF  FRONT  FND  MODULE 


FIGURE  3 


FRONT  END  TO  SIGNAL 


STANDARD  FRONT  END/SIGNAL  CONDITIONING  SECTION  INTERFACE 
FIGURE  5 


all  types  of  subsystems.  Particularly  noteworthy  is  the 
adaptability  of  the  interface  to  work  with  different  types 
of  avionic  subsystems.  Employing  a building  block  approach, 
memory  and  micrprocessor  elements  can  be  added  in  the 
data  transfer  chain  to  effect  special  requirements  of 
subsystems . 

It  has  been  proposed  to  the  SAE  A2-K  Subcommittee  on 
Multiplexing  that  the  above  described  interface  be  accepted 
as  a standard  for  LSI/Hybrid  type  Front  Ends.  The 
interface,  as  defined  in  Figure  5,  incorporates  all  the 
necessary  functions  to  work  with  the  various  signal 
conditioning  and  I/O  devices  which  directly  interface 
with  the  air  vehicle  subsystems. 

When  the  RT  is  involved  with  EMUX  type  signal  functions, 
the  signal  conditioning  section  of  the  RT  consists  of 
Discrete  I/O  modules,  A/D  Modules  and  D/A  Modules,  shown 
in  Figure  4 as  a Type  1 interface.  When  the  MUX  system  is 
to  interface  with  an  avionics  subsystem,  the  RT , in  the 
majority  of  applications,  would  present  either  a Type  2 
or  Type  3 interface.  The  Type  2 interface  would  employ 
parallel  or  serial  digital  signal  conditioning  devices 
and  operate  in  a mode  wherein  the  data  is  transferred  to 
and  from  the  subsystem  in  a sequential  format,  word- 
synchronous  to  the  1553A  bus.  When  the  RT  must  interface 
with  avionics  subsystems  that  have  relatively  slow  clock 
rates  and  do  not  have  the  facility  to  interchange  data 
with  the  RT  as  described  above,  data  can  be  interchanged 
via  a data  block  memory  element  as  per  Type  3 interface. 

Memory  contained  in  the  RT  would  function  as  a data  depository 
enabling  the  subsystem  to  effect  block  data  transfer.  When 
operating  in  the  receive  mode,  data  words  could  be  placed 
in  memory  synchronous  with  bus  operation,  then  transferred 
to  the  subsystem  in  block  or  DMA  format  whenever  the 
subsystem  is  available.  A similar  process  for  data 
transfer  could  be  implemented  in  the  reverse  direction 
when  operating  in  the  transmit  mode.  In  this  mode,  the 
subsystem  could  load  the  memory  at  its  convenience  with 
the  RT  extracting  data  word-synchronous  with  the  bus 
operation.  Whether  Type  1,  2,  or  3 interfaces  are  employed, 
it  is  worthwhile  to  remember  that  the  Front  End/Signal 
Conditioning  Section  Interface  remains  the  same.  This 
same  interface  can  also  serve  a microprocessor  (contained 
in  the  RT)  that  could  be  employed  for  the  pre-processing 
of  data  and  BIT  information,  e.g.  a SOSTEL  type  system 
which  employs  impedance  measurements  to  determine  switch 
and  controller  status  plus  connector  and  harness  status. 


FRONT  END  MODULE 


The  multiplex  terminal  Front  End  has  previously  been 
described  in  its  relationship  with  the  signal  conditioning 
section.  It  is  now  time  to  describe  the  internal  make  up 
of  the  Front  End  Module.  The  four  devices  that  comprise 
the  Front  End  Module  are  depicted  in  Figure  3.  The  PROM 
is  optional  and  when  used,  provides  unlimited  versatility 
in  the  programming  of  a full  32  word  message.  The  one 
hybrid  device  is  the  Transmitter/Receiver.  The  two  LSI 
devices  are  the  Sync/Data  Detector  and  the  Encoder/Decoder 
Controller. 

The  Transmitter/Receiver  hybrid  device  provides  the 
following  functions: 

Data  Detection/Reception 
Command/Data  Sync  Detection 
Dead  Line  Detection 
Data  Transmission 

The  Sync/Data  Detector  (LSI  #1)  deals  with  subbit  timing 
and  provides  the  following  functions: 

Data  Detection  Timing 
Manchester  to  NRZ  Conversion 
Sync  Acquisition  and  Data  Detection 
Detection  of  Manchester  Encoding  Error 

The  Encoder/Decoder  and  Controller  (LSI  #2)  deals  with 
bit  timing  and  provides  the  following  functions: 

Message  Validation 
Message  Decoding 
Address  Decoding 
Mode  Command  Decoding 
Status/Data  Encoding 
Sync  Encoding 
Status  Encoding 
Manchester  Encoding 
Signal  Conditioning  Addressing 
Loudmouth  Timeout 
Redundancy  Interface 
Word  Transfer  Monitoring 
Status  Response  Control 
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All  lines  from  the  Signal  Conditioning  Section  to  LSI  #2 
which  are  common  to  dual  Front  End  Modules  are  tri-state 
configured  to  facilitate  paralleling  of  multiple  Front 
End  Modules.  Paralleling  of  Front  End  Modules  provides 
complete  redundancy  within  the  RT. 

STANDARD  FRONT  END/SIGNAL  CONDITIONING  INTERFACE 

The  functions  that  comprise  the  Front  End/Signal 
Conditioning  Interface  can  be  separated  into  the  four 
categories  shown  below: 

1.  Input/Output  Data  Buses 

2.  Module  and  Channel  Selection  Buses 

3.  Standard  Timing  and  Housekeeping  Functions 

4 . Handshaking  Functions 

The  handshaking  functions  are  associated  with  bidirectional 
transfer  of  digital  data  to  avionic  type  subsystems  and 
are  not  involved  in  the  handling  of  discrete  and  analog 
functions  in  EMUX  type  system  applications. 

Input/Output  Data  Bus  - Data  words  received  by  the  Front 
End  Module  from  the  MUX  bus  are  clocked  in  serial  format 
and  sequential  order  from  the  Front  End  Module  on  the 
output  data  bus  to  the  appropriate  signal  conditioning 
modules  selected  by  the  module  select  bus.  Data  words 
are  held  in  holding  registers  in  each  module  until  all 
validation  checks  are  made  before  being  outputted.  This 
process  applies  to  all  data  words,  whether  the  words  are 
to  be  outputted  as  discrete  signals,  analog  functions  or 
transferred  to  a subsystem  in  digital  format. 

Module  and  Channel  Select  (Address)  Bus  - The  module  select 
bus  is  comprised  of  three  lines  which  can  select  from  one  to 
eight  modules  and  a fourth  line  which  is  equivalent  to  the 
transmit/receive  function.  This  fourth  line  selects  either 
the  input  or  output  section  of  modules.  Studies  have  shown 
the  eight  modules  are  sufficient  to  handle  the  nominal 
quantity  of  output  (input)  functions  of  a RT.  An  example 
would  be  to  use  two  16  channel  A/D  Conversion  Modules  and 
six  16  bit  Discrete  Modules  to  output  26  analog  and  96 
discrete  signals  for  a full  32  word  bus  message 

Hughes  forsees  all  digital  data  transfer  with  avionic 
type  subsystems  to  be  effected  by  one  addressable  terminal 
per  each  subsystem.  This  one-on-one  approach  does  not 
require  module  and  channel  selection  for  transfer  of  digital 
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formatted  data.  The  channel  select  bus  is  comprised  of  four 
lines  which  provide  the  channel  selection  required  to  address 
the  16  channel  A/D  and  D/A  modules.  Discrete  and  digital 
data  transfer  does  not  require  the  use  of  the  channel 
selection  function. 

Standard  Timing  and  Housekeeping  - All  the  modules  used  in 
the  signal  conditioning  section  of  the  RT  make  use  of  these 
functions,  consisting  of  such  functions  as  Data  Load,  Gated 
Clock  and  Reset. 

Handshaking  Functions  - The  handshaking  functions,  i.e., 

Request,  I/O  Acknowledge,  Data  Strobe,  and  Message  Validation, 
are  used  by  both  the  serial  and  parallel  digital  modules  and 
the  subsystems  that  these  modules  service.  These  functions, 
which  could  be  interconnected  directly  between  the  Front 
End  and  the  Subsystem,  are  purposely  carried  through  the 
moudles.  This  accommodates  any  variation  in  digital  data 
signal  conditioning  brought  about  by  different  type  avionic 
subsystems.  Such  functions  as  mode  command  to  the  subsystem 
and  status  functions  from  the  subsystem  are  carried  directly 
across  the  interface  to  the  Encoder/Decoder  and  Control  LSI. 

Terminal  Address  Functions  - Although  not  part  of  the  Front 
End/Signal  Conditioning  Section  interface,  it  is  worthwhile 
to  note  the  five  terminal  address  lines  connected  to  the  , 

Encoder/Decoder  and  Controller  LSI.  These  lines,  in  all 
RT  installations,  would  be  brought  out  to  an  external 
connector  for  programming  the  address  of  the  terminal. 

SIGNAL  CONDITIONING  PROGRAMMING  CAPABILITIES  OF  THE  INTERFACE 

The  previously  described  interface  has  been  selected 
as  the  standard  interface  to  be  employed  in  all  future 
MIL-STD-1553A  Remote  Terminals  for  Hughes  weapons  and  avionic 
system  applications.  The  Front  End  Module,  via  the  interface, 
provides  the  functional  requirements  to  program  all  types 
of  signal  conditioning  circuitry  necessary  to  service  air 
vehicle  (A/V)  subsystems.  In  the  Front  End  Module,  space  is 
allocated  for  a PROM  which  can  provide  complete  signal 
conditioning  program  versatility.  The  PROM  is  addressed 
by  the  information  contained  in  the  Command  Word  fields 
(i.e.,  terminal  address,  T/R,  sub-address  and  word  count 
fields)  plus  progressive  word  and  bit  count.  As  yet,  a 
MUX  system  application  that  requires  unique  function 
addressing  or  multiple  sample  rates  which  would  require  the 
PROM  has  not  been  encountered. 
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Control  logic  in  the  Encoder/Decoder  and  Controller 
(LSI  #2)  has  been  designed  to  provide  two  versatile  signal 
conditioning  programs  without  need  of  the  PROM.  The  base 
line  program  (receive  or  transmit  mode)  provides  signal 
conditioning  addressing  and  timing  capabilities  for  16 
analog  functions  and  112  discrete  signals  or  seven  ports 
for  bidirectional  parallel  or  serial  digital  data.  The 
digital  ports  and  discrete  functions  can  be  traded  off  on 
the  basis  of  one  digital  port  per  16  discretes  to  form 
various  combinations  of  analog,  digital  and  discrete  data 
configurations.  The  described  conf iauration  applies  to 
the  terminal  operating  in  both  transmit  and  receive  modes. 

This  means  that  an  EMUX  type  RT  could  process  16  analog 
input  and  16  analog  output  functions  plus  112  discrete 
input  and  112  discrete  output  signals. 

A second  configuration  is  available  (obtained  by 
grounding  one  pin  of  the  programming  lines  to  LSI  #2)  if 
more  analog  channels  are  required.  This  option  provides 
for  servicing  24  analog  functions  and  64  discrete  signals, 
applicable  to  both  the  transmit  and  receive  modes.  The 
PROM,  when  used,  can  provide  unlimited  versatility  in 
signal  conditioning  programming  for  a full  message  of 
32  data  words.  Figure  2 shows  a signal  conditioning  PCB 
configured  for  16  analog  inputs,  16  analog  outputs,  32 
discrete  inputs  and  32  discrete  outputs.  The  terminal's 
analog  and  discrete  signal  conditioning  capability  can 
be  doubled  by  adding  a second  PCB  and  coding  the  Command 
Word  accordingly. 

Additional  functions  are  incorporated  in  the  terminal 
which  provides  system  application  versatility.  The 
terminal  recognizes  a terminal  address  field  of  all  ones 
(11111)  as  a broadcast  command  and  a sub-address  field  of 
all  zeros  (00000)  as  a mode  command.  The  broadcast  command 
is  normally  interpreted  by  all  terminals  as  either  a time 
correlation  function  or  as  a simultaneous  sample  command. 

The  mode  command  is  made  available  by  decoding  the  word 
count  field. 

It  is  significant  to  note  that  all  the  terminal's  logic, 
control,  and  programming  (smarts)  is  accomplished  in  the 
Front  End  Module  without  the  incorporation  of  a microprocessor 
or  assistance  from  the  host  subsystem.  And,  as  equally 
important,  the  Front  End  Module  can  work  with  any  type 
air  vehicle  subsystem  whether  it  requires  an  EMUX  or  AMUX 
type  MIL-STD-1553A  MUX  system. 


ABBREVIATIONS 


A/D 

Analog  to  Digital 

AMUX 

Avionics  Multiplex 

A/V 

Air  Vehicle 

BCIU 

Bus  Controller  Interface  Unit 

BIT 

Built  In  Test 

CITS 

Centralized  Integrated  Test  System 

D/A 

Digital  to  Analog 

DIM 

Discrete  Input  Module 

DOM 

Discrete  Output  Module 

EMUX 

Electrical  Multiplex 

FE 

Front  End 

FEM 

Front  End  Module 

I/O 

Input/Output 

LRU 

Line  Replaceable  Unit 

LSI 

Large  Scale  Integration 

MUX 

Multiplex 

NRZ 

Non  Return  to  Zero 

PCB 

Printed  Circuit  Board 

PROM 

Programmable  Read  Only  Memory 

RT 

Remote  Terminal 

SOSTEL 

Solid  State  Electrical 

T/R 

Transmit/Receive 

XMT/RCV 

Transmitter/Receiver 
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ABSTRACT 

The  paper  describes  the  architecture,  operation,  and  performance  of  a Bus 
Control  Interface  Unit  integrated  into  a prototype  DAIS  computer.  The  motiva- 
tion for  adopting  the  final  architecture  as  well  as  a programmer's  description 
of  the  operation  is  presented.  In  order  to  minimize  hardware,  both  control  and 
data  information  is  transferred  over  a DMA  channel.  Pre-established  software 
"mailboxes  and  pointers"  are  resident  within  the  processor  memory  to  control 
the  multiplex  bus.  The  bus  controller  is  a microprogrammed  microprocessor. 

The  processor/integrated  BCIU  has  been  successfully  integrated  into  an  avionics 
system  hotbench. 


1.0 


INTRODUCTION 


Tills  paper  will  describe  the  architecture,  operation,  and  performance  of  a 
Bus  Control  Interface  Unit  (BCIU)  integrated  into  a prototype  DAIS  Computer 
(AN/AYK- 15) . The  motivation  for  adopting  the  final  architec  ure  will  be  pre- 
sented as  well  as  a programmer's  description  of  the  operation  of  the  MII.-STD-1553 
channel  controller. 

Since  the  MII.-STD- 1553  communication  concept  is  still  relatively  young,  the 
comments  from  systems  programmers  utilizing  the  channel  will  be  presented.  These 
comments  have  been  reviewed  and  will  be  incorporated  into  future  versions  of  the 
bus  controller. 

Tills  work  was  done  to  satisfy  an  "in-house"  requirement  for  a computer  of 
the  DAIS  processor  capability  to  interface  to  a MIL-STD-1553A  bus. 


2.0  PRESENT  DAIS  CONFIGURATION 

The  current  DAIS  processor  and  multiplex  bus  controller  is  implemented  as 
two  separate  LRU's  (Line  Replaceable  Units):  a general  purpose  avionics  com- 

puter (DAIS  computer)  and  a BCIU  (Bus  Control  Interface  Unit.)  Each  LRU  is  a 
"stand  alone"  assembly  containing  power  supply,  conduction  cooling  assemblies 
and  fully  isolated  differential  electrical  interfaces.  Figure  II 1 illustrates 
the  present  configuration  and  compares  that  with  the  integrated  approach. 

Recognizing  the  inherent  savings  in  reaching  a single  LRU  configuration, 
considerable  Westinghouse  "in  house"  effort  has  been  expended  to  analyze  the 
functional  requirements  of  a MIL-STD-1553  mux  bus  controller  and  then  to  fa- 
bricate a BCIU  which  could  be  integrated  into  the  DAIS  computer  LRU.  Although 
remaining  functionally  compatible  with  the  DAIS  BCIU,  every  attempt  was  made  to 
minimize,  the  parts  count  in  the  integrated  BCIU.  Accordingly,  maximum  use  was 
made  of  the  currently  available  Schottky  LSI  circuits. 

3.0  PRESENT  DAIS  ARCHITECTURE 

Figure  2 illustrates  the  architecture  of  the  present  DAIS  Mux  Bus 
Controller.  Three  interface  units  within  the  DAIS  computer  LRU  are  required  to 
communicate  with  the  BCIU  LRU. 

The  PIO  (Peripheral  I/O)  interface  is  the  control  interface  with  the  BCIU. 
It  is  a sixteen  bit  parallel  accumulator  I/O  channel  used  to  initiate  and 
intercede  with  BCIU  activity.  Status  registers  within  the  BCIU  are  loaded 
and  read  using  this  interface. 

The  DMA  interface  is  a separate  16  bit  parallel  interface  used  for  data 
transfers  between  the  BCIU  and  the  DAIS  computer  memory.  Once  an  activity  is 
initiated  by  a command  on  the  PIO  interface,  any  associated  data  is  transferred 
over  the  DMA- interface . 

Finally,  BCIU  interrupts  and  discretes  are  interfaced  via  the  Interrupt  I/O 
modulo.  Tills  allows  the  BCIU  to  call  for  intervention  from  the  DAIS  computer 
whenever  necessary. 
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The  present  two  LRU  configurations  offer  flexibility  over  an  integrated 
BCIU  where  total  volume  and  weight  is  not  a consideration.  A new  control 
computer  may  be  used  for  the  investment  of  a BCIU  interface  design.  Similarly, 
a new  BCIU  may  be  uaed  provided  its  computer  interface  is  compatible  with  that 
of  the  present  system.  However,  in  an  application  where  it  is  important  to 
minimize  weight  and  volume  (such  as  installation  aboard  a fighter  aircraft), 
the  integrated  BCIU  has  a substantial  advantage  over  the  two  LRU  approach. 

In  addition  to  the  obvious  duplication  of  support  functions  such  as  power 
supplies,  card  guides,  and  cooling  assemblies  in  a two  LRU  configuration,  the 
generalized  I/O  interface  between  the  DAIS  computer  and  the  BCIU  requires  a 
significant  parts  investment.  Of  the  total  number  of  integrated  circuits 
required  to  perform  the  DAIS  computer  I/O,  approximately  75%  are  needed  to 
accomodate  the  BCIU  interface.  As  might  be  expected,  47%  of  these  devices  are 
the  differential  line  drivers  and  receivers  needed  simply  because  the  BCIU  and 
DAIS  computers  are  in  separate  LRU's.  It  is  for  these  reasons  that  an  alternate 
BCIU  approach  was  investigated  resulting  in  the  development  of  the  system  to  be 
described . 

4.0  INTEGRATED  BUS  CONTROLLER 

Figure  3 illustrates  the  architecture  chosen  for  a bus  controller  inte- 
grated into  an  operational  system  in  September  of  1976.  The  PIO  and  INTERRUPT 
modules  of  the  DAIS  computer  were  retained  to  provide  a general  peripheral  bus. 
However,  the  remaining  I/O  modules  were  replaced  with  the  MIL-STD-1553  Mux 
Controller  to  provide  a Mux  Controller/DAIS  Computer  within  a single  LRU. 

Figure  4 shows  the  structure  for  the  integrated  BCIU.  In  order  to  minimize 
the  interface  with  the  DAIS  computer,  both  control  and  data  information  is 
transferred  over  a DMA  channel.  Accordingly,  a pre-established  format  of 
software  "mailboxes  and  pointers"  is  resident  within  the  DAIS  memory  to  control 
the  Mux  channel  (see  section  5.0).  This  permits  a hardware  savings  over  the 
present  architecture,  since  the  Mux  Processor  to  PIO  channel  interface  was 
eliminated . 

The  Bus  Controller  was  partitioned  into  three  functional  areas.  The  "Mux 
Processor"  is  a micro-processor  based  control  processor  which  performs  control 
and  data  transfers  with  the  DAIS  DMA  system.  Also,  it  performs  the  serial 
data  transfer  and  error  checking  with  the  MIL-STD-1553  Detector. 

The  "1553  Detector"  forms  the  logic  interface  to  the  bus  formats.  It 
receives  encoded  data  from  either  of  the  redundant  1553  channels,  identifies 
the  sync  characters  and  extracts  the  serial  data  for  the  Mux  Processor.  The 
1553  Detector  is  also  responsible  for  digitally  filtering  all  incoming  data 
in  order  to  comply  with  the  1553-A  noise  specifications. 

Finally,  the  1553  "Transceiver"  comprises  the  electrical  interface  to  the 
1553  bus.  It  contains  the  transformer  coupling,  drive,  sense  circuits,  and 
termination  circuitry  necessary  to  communicate  with  the  bi-directional  1553  bus. 


It  Is  felt  that  this  form  of  partitioning  allows  the  maximum  in  flexibility 
from  one  application  to  the  next.  For  instance,  if  a particular  program  required 
a fiber  optic  bus,  the  Mux  Transceiver  would  be  replaced  with  a suitable  unit 
while  the  Mux  Processor  and  Mux  Detector  would  be  retained.  And,  of  course, 
similar  reasoning  may  be  applied  for  replacing  the  other  two  modules  should  tne 
need  arise  in  a particular  application. 

5.0  BCIU  SOFTWARE  - A FUNCTIONAL  DESCRIPTION 

Figure  5 is  a block  diagram  of  the  software  structure  used  by  one  of  the 
Westinghouse  integrated  BCIU  designs.  This  structure  resides  in  main  memory 
and  serves  as  the  organizational  vehicle  by  which  any  BCIU  activities, such  as 
data  transfers  between  terminals,  are  initiated  and  controlled.  The 
individual  words  making  up  the  elements  of  the  figure  are  installed  by  the 
programmer  during  software  development  and  are  accessed  by  the  BCIU  at  run  time 
via  DMA  cycles.  With  one  exception,  the  required  pointers  and  control  blocks 
may  be  placed  anywhere  in  memory  so  that  space  may  be  allocated  for  the  BCIU 
structure  in  the  most  appropriate  locations. 

A logical  breakdown  of  the  control  structure  yields  three  sub-structures: 

The  Sequence  List  Pointer,  the  Sequence  List,  and  the  Activity  Control  Block 
(ACB).  The  ACB,  as  will  be  described  further  on,  is  a fixed  length  block  of 
words  containing  the  parameters  necessary  to  define  a single  BCIU  activity. 

The  Sequence  List,  which  is  a contiguous  list  of  pointers,  organizes  a group 
of  ACB's  into  a functional  unit  called  an  Activity  Cycle.  The  purpose  of  the 
Sequence  List  Pointer  - location  10h  - is  to  direct  the  BCIU  to  the  top  of 
the  Sequence  List  so  that  execution  of  the  cycle  can  begin. 

The  first  act  of  the  BCIU  upon  power  up  is  to  clear  the  Sequence  List 
Pointer  - after  which  it  goes  into  the  idle  mode  where  it  continually  monitors 
the  pointer  value.  The  main  processor  may  then  store  a non-zerc  value  into 
location  10))  causing  the  BCIU  to  leave  the  idle  mode  and  to  start  executing 
the  Activity  Cycle  beginning  at  the  given  non-zero  address.  When  the  execution 
of  the  cycle  is  complete  the  BCIU  again  clears  the  Sequence  List  Pointer  and 
resumes  idle  mode. 

While  there  is  only  one  Sequence  List  Pointer  - at  a fixed  location  - 
there  will  typically  be  several  Activity  Cycles  in  main  memory  each  with  its 
own  Sequence  List  and  associated  ACB's.  Executing  an  Activity  Cycle  is  the 
process  of  performing  the  activities  defined  by  the  Activity  Control  Blocks 
in  the  order  in  which  the  Sequence  List  refers  to  them.  Once  initiated,  this 
procedure  is  carried  out  automatically  by  the  BCIU  making  further  intervention 
by  the  main  processor  unnecessary.  Each  Activity  Cycle,  therefore,  represents 
an  individual,  complex,  multi-activity  communication  task  which  is  performed 
with  a minimum  of  processor  supervision. 

The  Activity  Control  Block  takes  the  form  shown  in  figure  6.  The  Activity 
Control  Word  (ACW)  - the  first  word  in  the  block  - identifies  the  activity  class, 
e.g.,  message  transmission,  and  contains  several  modifier  bits  which  influence 
execution.  Table  1 lists  the  available  BCIU  activities  and  their  equivalent 
activity  codes.  An  ACB  specifying  a Bux  Controller  to  Remote  Terminal  transfer 
(BC*RT)  for  example,  would  have  an  ACW  of  the  1000"series"  i.e.,  the  ACW  will 
be  1000))  with  the  possible  addition  of  modifier  bits  in  the  second  hex  digit. 

A brief  description  of  the  meaning  of  each  activity  type  is  given  in  the  table. 
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The  last  two  activity  codes  listed  are  unique  in  that  they  are  activity 


cycle  terminators.  One  of  these  must  appear  as  the  last  activity  of  any 
complete  Activity  Cycle.  Terminate  (7000][)  causes  the  BCTU  to  clear  the 
Sequence  List  Pointer  and  interrupt  the  processor  - signalling  the  end  of 
the  cycle.  Recycle  (6000ji)  causes  execution  of  the  Activity  Cycle  to  be 
restarted  from  the  top.  Cyclic  execution  will  continue  in  this  case  until 
the  main  processor  intervenes  by  clearing  location  10^. 

The  Status  Mask,  Bus  Command,  Status  Word,  First  Word  Address  (FWA) , 

Current  Word  Address  (OTA) , and  Last  Word  Address  (LWA)  are  important  only 
for  data  transfer  activities  (BORT  or  RT>»BC).  The  status  word  received 
from  a Remote  Terminal  during  a message  transfer  is  written  into  the  Status 
Word  position  in  the  ACB.  The  Status  Mask  is  applied  to  this  word  and  if 
the  resulting  pattern  is  non-zero  an  interrupt  is  generated  by  the  BCIU. 

The  processor  can  be  kept  informed  about  errors  in  data  transmission  via  this 
feature.  The  Bus  Command  is  the  message  command  word  which  will  be  put  on 
the  bus,  preceded  by  a command  sync,  as  part  of  a standard  MIL-STD-1553 
formatted  message.  Consequently,  the  AOT  and  the  Bus  Command  must  agree  with 
respect  to  the  direction  of  transfer,  i.e.,  receive  or  transmit.  The  FWA  and 
LWA  are  memory  buffer  delimiters  indicating  the  address  of  the  first  and  last 
word  of  the  buffer  area  respectively.  Message  to  be  transmitted  are  taken 
from  this  area,  and  received  messages  are  written  into  it.  The  CWA  is  used 
by  the  BCIU  to  mark  the  position  within  the  buffer  currently  being  read  or 
written. 

The  last  three  words  of  the  ACB  are  concerned  exclusively  with  the 
interrupt  system  employed  by  the  BCIU.  In  the  event  that  it  should  be  necessary 
for  the  BCIU  to  interrupt  the  processor  during  the  execution  of  an  activity,  a 
2-step  operation  is  performed  in  which  (1)  the  contents  of  the  Priority  Number 
word  (PRNO)  are  written  into  the  location  pointed  to  by  the  Interrupt  Address 
word  (IADR) , and  (2)  an  interrupt  code  is  written  into  the  Interrupt  Code 
Word  (ICOD)  to  identify  the  cause  of  the  interrupt.  Since  PRNO  is  written 
non-destructively  it  can  be  used  to  simulate  a vectored  priority  interrupt 
system  even  though  only  one  interrupt  channel  is  available. 

6 . 0 OPERATIONAL  PERFORMANCE 

A thorough  bench-test  of  the  BCIU  and  Remote  Terminal  capability  has  been 
performed  using  the  hardware  configuration  shown  in  figure  7.  In  this  system 
a DAIS  computer,  fitted  with  the  BCIU  cards,  communicates  with  a simple  256 
word  memory  also  serviced  by  a BCIU.  A direct  I/O  channel  from  the  computer 
to  the  memory  board  provides  the  means  for  loading  and  examining  the  memory 
during  the  test.  Depending  on  the  activities  being  tested,  either  terminal 
unit  can  be  operated  as  Bus  Controller  or  Remote  Terminal. 

In  the  lab,  under  normal  ambient  temperature  and  noise  conditions,  the 
system  was  run  through  a series  of  activity  exercises  including  message 
transfers  of  1-32  words,  block  transfers  of  arbitrary  length,  receiver 
switching,  and  Bus  Controller  to  Remote  Mode  switching.  When  satisfactory 
performance  had  been  achieved  with  these  basic  tasks  a more  extensive  set  of 
system  software  for  an  operational  program,  was  used  to  test  the  BCIU  perfor- 
mance in  a real-time  communication  environment.  The  results  were  positive. 
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The  computer-BCIU  combination  described  here  has  been  integrated  into  an 
avionics  system  hotbench  successfully. 

Among  the  comments  received  about  the  BCIU  characteristics  from  the 
programming  group  were  two  that  will  be  given  attention  in  the  future.  First, 
the  control  structures  should  be  designed  so  that  they  need  not  be  written 
into  after  initialization,  thereby  allowing  the  use  of  protected  memory. 

Second,  the  interrupt  system  should  allow  the  masking  of  all  interrupts  on  an 
individual  basis.  There  will  be  little  difficulty  in  making  these  and  other 
optimizations . 

The  micro-programmed  nature  of  the  real-time  processing  hardware  used 
in  the  BCIU  makes  it  possible  for  the  device  to  be  tailored  to  meet  a 
particular  set  of  specifications  through  firmware  modification  alone.  The 
device  is,  in  fact,  a special-purpose  processor  with  very  little  "hardwired" 
intelligence  so  that  the  personality  of  the  unit  is  embodied  almost  entirely 
in  its  firmware.  Within  time  and  ROM  limitations  the  architecture  of  the  unit, 
as  it  currently  exists,  can  be  programmed  to  implement  any  data  handling 
activities  that  are  likely  to  be  required  by  a particular  application.  As  an 
example  of  this  flexibility,  a case  occurred  in  which  it  became  necessary  to 
extensively  modify  the  handling  of  the  "mode"  command.  As  it  was  originally 
implemented  a Bus  Command  with  a sub-address  field  of  zero  treated  as  a self- 
contained  special-purpose  command  that  was  transmitted  without  accompanying 
data  words.  A new  implementation,  requiring  the  concurrent  transfer  of  a 
biork  of  N data  words,  including  a destination  address  word  and  special  word 
count  handling,  was  micro-coded  and  installed  in  firmware  with  no  attendant 
changes  in  hardware. 


ACTIVITY 
CONTROL  WORD 

ACTIVITY 

IMPLIED 

MEANING 

1000H 

BC  RT 

A 1553  formatted  message  is  to  be  trans 
mitted  to  a Remote  Terminal. 

2000 

NOP 

The  ACB  is  skipped. 

3000 

RT  BC 

A Remote  Terminal  is  to  be  commanded  to 
transmit  a 1553  formatted  message  to 
the  Bus  Controller. 

4000 

RCVR  SELECT 

Hardware  Receiver  A or  B is  selected. 

5000 

M/R  SWITCH 

Bus  Controller  is  to  revert  to  Remote 
Mode . 

6000 

RECYCLE 

End  of  current  Activity  Cycle.  Restart 
execution  from  the  top. 

7000 

TERMINATE 

End  of  current  Activity  Cycle.  Clear 
Sequence  List  Pointer  and  go  to  idle 
mode . 

TABLE  1.  BCIU  ACTIVITY  CODES  AND  MEANINGS. 
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1.  Volume 


1.0  p.u. 


.722  p.u. 


278  p.u. 


2. 

Weight 

1.0  p.u. 

.725  p.u. 

,275  p.u. 

3. 

Power 

1.0  p.u. 

.698  p.u. 

.302  p.u. 

H. 

Reliability 

1.0  p.u. 

.715  p.u. 

.285  p.u. 

Fig.  ill  - Comparison/  Major  System  Parameters 
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Fig.  # 3 - Integrated  Bus  Control  Architecture 
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IDAMST:  INTEGRATED  DIGITAL  AVIONICS  FOR  THE 
ADVANCED  MEDIUM  STOL  TRANSPORT 

W.  A.  Crossgrove  and  Dr.  Leroy  A.  Smith 
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ABSTRACT 

The  objective  of  this  paper  is  to  describe  briefly  the 
results  of  a program  to  define  the  operational  flight  program 
and  the  operational  test  program  for  an  integrated  Digital 
Avionics  system  for  the  Medium  STOL  Transport  (IDAMST)*.  This 
effort  was  part  of  an  Air  Force  Avionic  Laboratory  program 
to  specify  a candidate  avionics  design  based  on  DAIS  technol- 
ogy. The  approach  involved  the  development  of  software  re- 
quirements derived  from  the  system  analysis  of  the  hardware 
baseline  and  the  operational  analysis  of  the  AMST  mission. 

The  IDAMST  software  design  was  based  on  DAIS  architecture 
and  adapted  as  required  to  meet  the  IDAMST  requirements.  The 
DAIS  architecture  proved  to  be  flexible  allowing  the  design 
to  be  extended  to  IDAMST  without  major  change.  The  IDAMST 
system  defined  satisfies  the  functional  and  operational  re- 
quirements of  the  AMST.  The  design  consists  of  a dual  redun- 
dant processor  with  a reloadable  backup  processor  and  a dual 
redundant  bus. 


INTRODUCTION 

The  objective  of  the  Specification  for  IDAMST  (integra- 
ted Digital  Avionics  for  the  Medium  STOL  Transport)  software 
program  was  to  define  the  operational  flight  program  and  the 
operational  test  program  for  a highly  integrated  digital  avi- 
onics system.  The  effort  was  a part  of  the  Air  Force  Avionics 
Laboratory's  (AFAL)  program  to  specify  a candidate  avionics 


* The  work  reported  on  by  this  paper  was  supported  by  Air 
Force  Avionics  Laboratory,  Contract  No.  F3361  5-76-C-  1 099  , 
Mr.  Larry  Gutman  Contract  Monitor. 
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system  design  based  on  DAIS  (Digital  Avionics  Information 
System)  technology  for  the  AMST. 

The  following  key  ground  rules  and  assumptions  were 
established  to  govern  the  conduct  of  technical  activity  on 
this  program: 

The  mission/operational  analysis  was  based  upon  an  AFAL 
provided  mission  scenario. 

A two-man  crew  was  assumed. 

The  basic  avionic  sensor  list  was  supplied  by  the  AFAL. 

Sensor  performance  was  assumed  adequate  for  mission  tasks 
as  stated  in  mission  scenario. 

The  extent  of  the  integration  is  essentially  as  scoped 
within  AFAL's  IDAMST  study  report,  Vol.  11. 

Navigation 

Communication 

Controls  and  Displays  (HUD,  HSD,  MPD,  etc.) 

System  Status  Monitoring 

Consideration  of  the  potential  AMST  design  as  currently 
implemented  in  the  Boeing  AMST  prototype  (YC-14)  was 
used  to  facilitate  system  definition  with  respect  to 
physical  size  constraints,  location  of  hardware,  and 
system  design. 

PROGRAM  APPROACH 

The  approach  involved  the  development  of  software  re- 
quirements derived  from  a system  analysis  of  the  IDAMST 
hardware  baseline  (14)  and  an  operational  analysis  of  the 
AMST  mission  (21,  Vol.  II).  The  software  requirements  were 
subsequently  develop ed  into  a specific  IDAMST  software  design 
and  described  in  terms  of  functional  and  architectural 
characteristics.  The  resultant  design  is  documented  in  four 
separate  Computer  Program  Development  Specifications  (22-25) 
and  summarized  in  a final  report  (21). 

SYSTEM  DEFINITION 

The  avionic  sensors,  aircraft  system  monitoring  equipment, 
mission  processors  and  control  and  displays  are  integrated 
into  the  IDAMST  system  and  form  an  overall  architecture  that 
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is  similar  to  the  basic  design  of  DAIS.  The  avionic  sensors 
are  functionally  partitioned  into  the  following  six  types: 
Instrument  and  Aircraft  Systems,  Navigation  Systems,  Commu- 
nication and  Identification  Systems,  Radio  Aids  to  Navigation 
Systems,  Defensive  Countermeasures  Systems,  and  Payload  Sys- 
tems. For  IDAMST  the  system  physically  consists  of  221 
avionic  sensors,  61  control  and  display  elements,  and  14 
IDAMST  integration  elements.  A block  diagram  of  the  IDAMST 
system  showing  the  interconnection  of  the  296  LRU's  is  pro- 
vided by  Figure  1 . 


The  physical  layout  of  the  IDAMST  system  as  applied  to 
the  Boeing  YC-14  airplane  contains  four  integration  areas. 
These  are:  nose  avionics  bay,  cargo  avionics  bay,  flight 

deck  avionics  bay,  and  flight  deck  panel  area.  Location  of 
the  avionics  equipment  in  relation  to  the  above  areas  pro- 
vides separation  of  redundant  functions  while  providing  con- 
ventional locations  of  equipment  associated  with  transport 
vehicles.  System  integration  is  provided  by  the  IDAMST  archi- 
tecture  which  uses  the  data  communication  network  and  the 
mission  software  partitioning  to  achieve  the  IDAMST  functions, 
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The  IDAMST  system  design  and  architecture  can  best  be 
described  as  a federated  processing  system  using  standard 
interfaces,  standard  communication  methods,  general  purpose 
military  qualified  processors,  and  existing  avionic  sensors. 
The  advantage  of  such  a system  is  to  produce  commonality  of 
integration  techniques  and  hardware  for  many  vehicles  regard- 
less of  integration  needs.  The  components  allow  standard 
hardware  developments,  reusable  software  modules,  and  common 
system  engineering.  To  extend  these  methods  to  IDAMST,  the 
DAIS  core  element  hardware  and  software  architecture  was 
adapted  to  satisfy  the  unique  requirements  of  the  AMST. 


The  operation  of  the  IDAMST  system  is  maintained  by  the 
master,  monitor  and  remote  processors.  Functionally,  the 
master  processor  has  been  assigned  the  pilot  functions  as 
well  as  the  system  executive  activities.  The  monitor  pro- 
cessor, likewise,  has  been  assigned  the  copilot  functions  and 
also  performs  the  monitor  executive  functions  to  assume  con- 
trol in  case  of  master  failure.  The  remote  processor  is 
assigned  the  aircraft  monitor  and  control  functions.  Each  of 
the  processors  interface  with  the  communication  network  via 
a bus  control  interface  unit  (BCIU).  The  master  processor 
and  its  associated  BCIU  has  been  assigned  prime  bus  control. 
The  ous  communication  is  a command/response  format  (MIL-STD- 
1553).  The  bus  is  operated  svn cn ronous 1 y with  the  maximum 
signal  address  rate  at  64  times  a second  (a  minor  frame). 
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Figure  1.  IDAMST  System  Block  Diagram 


Separation  of  avionic  sensors  are  maintained  within 
IDAMST  by  similar  and  dissimilar  redundancy.  Similar  re- 
dundancy provides  two  or  three  identical  units  interfaced  to 
different  remote  terminals  and  processed  in  separate  mission 
processors  with  the  calculated  results  compared.  Dissimilar 
redundancy  provides  a functional  capability  which  can  be 
obtained  from  two  or  three  different  types  of  hardware  items. 
In  most  cases,  these  devices  are  also  interfaced  and  proces- 
sed in  separate  remote  terminals  and  mission  processors  and 
the  results  compared.  In  this  way,  avionics  separation  by 
functional  partitioning  is  maintained.  In  a somewhat  differ- 
ent way,  redundancy  and  separation  is  orovided  in  the  controls 
and  displays  area.  The  pilot-copilot  functions  are  separated 
both  functionally  and  physically  by  using  four  remote  termin- 
als. These  terminals  are  located  in  two  geographical  loca- 
tions: flight  deck  panel  area  and  flight  deck  avionics  bay. 

Therefore,  separation  of  pilot-copilot  functions  requires  the 
use  of  two  remote  terminals  per  area.  To  obtain  maximum 
flexibility  under  several  failure  conditions,  all  of  the  crew 
controls  and  displays  were  interfaced  to  both  remote  terminals 
This  hardwired  redundant  interface  produces  within  each  LRU  a 
prime  and  a passive  backup  interface  to  the  IDAMST  system, 
thus  allowing  several  failures  before  loss  of  pilot  or 
copilot  functions. 


SYSTEM  ANALYSIS 

The  system  analysis  activity  used  two  analytical  tech- 
niques. The  first  was  the  systematic  analysis  through  the 
generation  of  operational  sequence  diagrams  from  a composite 
AMST  mission  scenario  (1).  This  technique  yielded  the  follow- 
ing definition  of  the  minimum  mission  functions  versus  the 
basic  AMST  missions  as  shown  in  Figure  2. 

Given  the  above  minimum  functional  capability  and  the 
baseline  equipment  list,  the  IDAMST  functions  for  integrated 
avionics  were  defined  as  shown  in  Figure  3.  The  Figure  dif- 
ferentiates between  the  duplicate  functions  performed  by  the 
pilot  and  copilot  processors  and  the  non-mission  critical 
functions  contained  in  the  remote  processor. 

The  second  analytical  technique  used  the  AFAL  developed 
MUXSIM  program.  MUXSIM  is  a computer  hosted  analysis  and 
design  aid  used  to  investigate  MIL-STD-1 553  type  data  commu- 
nication networks. 

Upon  review  of  the  eight  MUXSIM  static  models  (26),  it 
was  deter, nined  that  the  models  that  closely  represent  the 
IDAMST  hardware  implementation  requirements  are  the  three 
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Figure  2.  Required  Minimum  Mission  Functional  Capability 


models  involving  transfer  disciplines  using  B C I U broadcast 
reception.  These  models  are: 

Termi n a 1 - to - termi n a 1 data  transfer  with  BCIU  broadcast 
reception  (Model  SE). 

Te rmi n a 1 - to-cen tr a 1 control  1 er- to-termi nal  data  trans- 
fer with  BCIU  broadcast  reception  (Model  SF). 

Hybrid  combination  of  the  above  two  models  which  result 
in  the  lowest  bus  loading  for  each  update  rate  (Model 
SG). 

An  analysis  of  the  data  network  traffic  loading  for  the  above 
three  models  (Figure  4),  shows  that  Model  SE  has  a consider- 
ably lower  loading  than  Model  SF.  The  results  of  Model  SG 
have  shown  no  significant  reduction  over  Model  SE.  Based  on 
these  results  it  was  considered  that  an  implementation  such 
as  that  represented  by  Model  SE  should  be  selected  since  it 
provides  a lower  data  traffic  loading  than  Model  SF  and  pro- 
vides no  significant  difference  from  the  more  complex  approach 
represented  by  Model  SG. 


Figure  3.  IDAMST  Function  Identification  List 


% UTILIZATION  (TIME) 


WITH  BROADCAST  RECEPTION  WITH  BROADCAST  RECEPTION 

BY  ONE  B CIU  BY  THREE  BCIU'S 

Figure  4.  Communication  Techniques 


The  original  analytical  experiment  was  conducted  using 
one  processor  as  the  active  BCIU  (or  Master  Controller).  A 
second  analytical  experiment  was  subsequently  conducted 
using  all  three  processors  with  the  capability  of  actively 
receiving  messages  destined  for  the  central  message  control- 
ler (broadcast  reception).  In  this  model  any  data  from  a 
given  terminal  destined  for  more  than  one  processor  can  be 
grouped  to  form  a single  message  transmission,  thereby  elim- 
inating the  requirement  for  individual  messages  to  each  pro- 
cessor. The  results  of  this  experiment  (Figure  4)  involving 
the  three  pertinent  models  show  a significant  reduction  in 
data  network  traffic.  A secondary  consideration  is  that  any 
BCIU  can  receive  all  processor  traffic,  thereby  eliminating 
the  need  for  data  network  message  rerouting  when  the  processor 
assignments  are  changed  in  the  event  of  reconfiguration. 
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Therefore,  the  data  transfer  discipline  of  termi nal -to-termi - 
nal  (represented  in  Model  SE)  using  the  all  BCIU  broadcast 
reception  was  chosen. 

The  IDAMST  system  utilizes  12  different  types  of  stand- 
ard interface  modules:  single  ended  discrete,  differential 

discrete,  switch  closure  (open/gnd),  switch  closure  (open/ 
28V),  single  ended  dc  analog,  differential  dc  analog,  single 
ended  ac  analog,  differential  ac  analog,  synchro,  serial 
digital,  pulse  and  resolver.  The  interface  modules  are 
located  in  11  remote  terminals  with  a distribution  of  inter- 
faces as  required  by  the  avionics  located  in  each  geograph- 
ical area.  The  effective  utilization  of  the  available  inter- 
face spaces  for  each  remote  terminal  varies  between  40%  as  a 
minimum  to  78%  as  a maximum. 

The  performance  requirements  of  the  mission  processors 
and  the  remote  terminals  are  discussed  in  regard  to  the  com- 
munication network.  MIL-STD-1553  allows  31  distinct  messages 
to  a remote  terminal  by  using  the  five  subaddress  bits.  The 
MUXSIM  analysis  of  the  IDAMST  remote  terminals  revealed  that 
the  greatest  number  of  distinct  messages  sent  to  any  remote 
terminal  was  17.  However,  BCIU's  are  not  restricted  by  this 
addressing  limitation.  The  only  requirement  for  a BCIU  is 
that  on  any  minor  cycle  there  be  no  more  than  31  different 
messages.  The  analysis  yielded  81  messages  received  by  the 
BCIU's,  as  a worst  case,  with  the  distribution  as  shown  below 
in  Figure  5. 


Figure  5.  BCIU  Distinct  Messages  by  Update  Rate 


All  81  messages  are  not  required  by  each  processor;  the 
actual  number  of  messages  is  based  on  software  partitioning. 
The  pilot-copilot  processors  will  require  the  same  types  of 
messages  since  they  perform  redundant  functions,  while  the 
remote  processor  requires  fewer  messages,  because  it  performs 
only  aircraft  monitoring  functions.  Since  avionics  control 
can  originate  from  only  one  (master)  processor,  the  pilot 
processor  has  a higher  number  of  transmitted  messages  than 
the  other  two  processors.  The  entire  load  on  the  bus  varies 
from  one  minor  frame  to  another  as  can  be  seen  in  Figure  6. 
The  cumulative  bus  loading  is  48.7%  of  the  total  time  avail- 
able. This  load  is  distributed  among  avionics  (24.7%),  con- 
trols and  displays  (23.1%)  and  interprocessor  communication 
(0.9%) . 


MODEL  SE:  TERMINAL  TO  TERMINAL  WITH  BROADCAST  RECEPTION  BY  THREE  BCIU'S 


SOFTWARE  DESIGN 
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The  IDAMST  software  design  represents  the  application  of 
DAIS  technology  to  the  specific  functional,  architectural 
and  configurational  requirements  of  the  AMST  aircraft.  The 
IDAMST  software  is  designed  to  satisfy  the  functional  re- 
quirements for  both  normal  and  failure  modes.  Architec- 
turally, the  IDAMST  software  is  similar  to  DAIS  with  some 
modification  and  change  occurring  at  the  detailed  operational 
level.  The  specific  IDAMST  software  configuration  is  by 
necessity  different  from  DAIS  because  of  the  contrast  in 
operational  requirements.  However,  where  functional  common- 
ality exists,  the  IDAMST/DAIS  structure  allows  a high  degree 
of  reuse  of  DAIS-speci f i ed  software  components. 

IDAMST  OPERATIONAL  FLIGHT  PROGRAMS 

The  IDAMST  Operational  Flight  Programs  (OFP)  are  organ- 
ized on  the  basis  of  DAIS  architectural  design  and  divided 
into  three  categories:  1)  OFP  executive  software;  2)  OFP 
applications  software;  and  3)  OFP  error  handling  and  recov- 
ery (EHAR)  software. 

The  executive  software  provides  the  control  of  the 
applications  and  EHAR  software  and  isolates  or  buffers  these 
programs  from  the  mechanism  of  data  transmission  between  pro- 
cessors and  avionic  equipment.  The  executive  software  controls 
this  data  transmission  mechanism. 

The  applications  software  provides  the  detailed  software 
functions  to  support  the  AMST  mission  and  operational  require 
ments.  The  applications  software  communicates  with  the 
avionics  equipment,  crew  controls  and  displays  via  the  execu- 
tive software. 

The  EHAR  software  provides  system  error  recovery  due  to 
malfunctions  detected  in  avionics  equipment,  the  data  commu- 
nications network  or  the  mission  processors.  The  mechanism 
for  EHAR  is  distributed  throughout  the  executive  and  appli- 
cations software. 

IDAMST  SOFTWARE  ARCHITECTURE 

Although  the  IDAMST  software  architecture  has  been  deri- 
ved from  the  DAIS  architecture  there  are  some  significant 


differences  in  the  functioning  of  the  monitor  processor.  The 
IDAMST  software  is  distributed  among  three  processors,  all  of 
which  are  actively  performing  mission  operations.  Two  of  the 


three  processors  have  virtually  duplicate  software.  One  pro- 
cessor is  devoted  to  processing  requests  and  displays  for  the 
pilot  and  the  other  is  devoted  to  the  copilot.  The  primary 
differences  between  these  two  processors  is  that  one  contains 
the  master  executive  which  is  responsible  for  controlling  the 
order  of  messages  transmitted  over  the  bus  and  for  determin- 
ing if  there  has  been  a degenerative  failure  or  error  in  the 
other  processors.  The  other  processor  contains  the  monitor 
executive.  In  the  event  of  an  error  the  monitor  executive 
must  assume  control  of  the  data  communication  network  and  re- 
configure the  system. 

During  recovery  from  an  error,  the  software  in  either  of 
the  two  processors  is  capable  of  interfacing  with  both  the 
pilot  and  copilot  devices.  Both  the  master  and  monitor  pro- 
cessors contain  some  active  and  inactive  software  during 
normal  operation;  however,  most  redundant  ^unctions  are 
active  to  provide  an  error  detection  capability. 

The  local  executive  programs  are  identical  in  all  three 
processors,  although  the  task  tables  contain  different  en- 
tries. The  local  executives  are  responsible  for  satisfying 
the,  real-time  request  of  the  tasks.  The  executive  must  dis- 
patch tasks  when  events  have  been  appropriately  set  either 
by  the  clock  or  by  other  tasks  and  must  communicate  with  the 
local  executives  in  the  other  processors  in  order  to  synchro- 
nize tasks  in  all  three  processors. 

The  applications  software  is  organized  in  a hierarchial 
control  tree  structure.  The  tasks  are  separted  into  control- 
ler and  calculator  functions.  A task  can  only  be  invoked  by 
a unique  task  at  the  next  higher  level  of  control.  However, 
events  upon  which  the  task  activation  is  based  can  be  signal- 
led by  tasks  at  all  other  levels.  A task.must  be  scheduled 
and  activated  before  it  can  begin  execution. 

In  IDAMST,  the  master  sequencer  is  the  top  level  control- 
ler task  (scheduled  by  the  master  executi ve ) . ) It  schedules 
the  subsystem  status  monitor,  configurator  and  request  pro- 
cessor. The  primary  controller  of  the  next  level  of  control 
is  the  configurator  which  schedules  and  cancels  most  of  the 
equipment  interface  functions  (EQUIPS),  operational  sequencers 
(OPS  - next  level  of  control  based  on  pilot  requests),  com- 
putational specialist  functions,  and  display  interface  func- 
tions. The  configurator  in  the  master  processor  is  responsi- 
ble for  the  control  of  the  applications  tasks  in  the  master 
and  remote  processors  while  the  monitor  configurator  controls 
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its  own  applications  software  in  accordance  with  synchroniza- 
tion events  communicated  between  the  master  and  monitor  con- 
figurators. 

PROGRAM  CONCLUSIONS 

IDAMST  AS  AN  AMST  AVIONICS  SYSTEM  CANDIDATE 

The  IDAMST  design  will  satisfy  the  AMST  operational  re- 
quirements. The  hardware  and  software  design  satisfies  the 
mission  essential  requirements,  provides  growth  and  system 
monitoring  features  that  will  facilitate  the  operation  of  the 
AMST  with  a two-man  crew.  However,  the  fundamental  questions 
that  immediately  arise  are:  1)  is  the  IDAMST  configuration 
required  for  an  AMST  operated  by  a two  man  crew;  2)  if  IDAMST 
is  not  required,  what  is?  In  the  course  of  the  system  analy- 
sis which  was  performed  during  this  program,  it  was  apparent 
that  some  degree  of  functional  integration  is  necessary  to 
support  performance  requirements  as  well  as  a two  man  crew. 
The  need  for  processing  capability,  especially  in  the  navi- 
gation system,  is  a requirement  to  achieve  the  air  drop 
accuracy.  Also,  air  data  computations,  system  monitoring 
functions,  and  an  automatic  test  capability  requires  on- 
board processing. 

Low  procurement  cost  is  the  prime  factor  that  conflicts 
with  the  offered  advantages  of  a DAIS  "like"  design  for  the 
AMST.  The  life  cycle  cost  advantages  are  currently  over- 
shadowed by  the  initial  development  requirements  of  such  a 
system.  Therefore,  using  only  procurement  cost  austerity  and 
an  essential  mission  capability  as  key  evaluation  factors, 
IDAMST  is  initially  more  expensive  and  provides  more  than 
the  mission  essential  capability. 

If  IDAMST  is  not  optimum,  then  what  design  is?  It 
appears  that  a design  having  multiple  processors,  an  integra- 
ted data  communication  network  (bus  structure)  and  integrated 
controls  and  displays  is  required.  I DAMST , as  an  avionics 
system  type  satisfies  this  criteria.  However,  specific 
details  remain:  How  much  integration  is  necessary?  How 

extensive  must  CRT  type  displays  be  employed?  What  processor 
capability  is  required  and  how  many?  These  questions  indi- 
cate that  prior  to  the  final  AMST  design,  additional  studies 
are  required. 


A dual  redundant  processing  design  was  configured  for 
IDAMST.  One  processor  is  designated  as  a pilot's  processor 
while  the  other  the  copilot's.  Redundant  and  active  software 
is  processed  in  each  of  these  computers.  Functional  separa- 
tion is  maintained  between  the  pilot  and  copilot  controls  and 
displays  through  the  processors  out  to  redundant  sensors  when 
redundant  hardware  is  provided.  Failure  of  either  processor 
will  not  reduce  the  minimum  mission  essential  capability  but 
will  void  functional  separation.  The  third  processor,  if 
commanded  by  the  crew,  will  reconfigure  and  restore  function- 
al redundancy  and  separation.  This  design  is  considered  to 
be  conservative  and  as  a result  requires  more  processor  capa- 
bility and  potentially  a higher  degree  of  bus  traffic  than 
other  configurations.  The  approach  departs  from  the  DAIS 
software  configuration.  However,  this  conservative  approach 
simplifies  reconfiguration,  and  is  considered  to  be  a step 
towards  simplifying  the  IDAMST  system  design  to  a more  austere 
level.  Also,  i z is  considered  that  the  requirement  for  three 
mission  processors,  when  put  into  proper  perspective,  is  not 
over  conservative.  The  third  processor  capability  is,  in 
essence,  a prerequisite  to  an  on-board  test  capability.  The 
use  of  the  test  computer  as  a backup  mission  processor  also 
improves  the  mission  reliability. 


DAIS  ARCHITECTURE  AS  APPLIED  TO  THE  AM  ST 


The  DAIS  architecture,  including  the  structured  approach 
to  the  software  design  proved  to  be  readily  adaptable  to  the 
AMST  when  considering  an  integrated  digital  avionics  design. 

As  a model,  DAIS  served  its  purpose  well  by  providing  a point 
of  reference  to  trade  up  or  down.  The  flexibility  allowed  by 
the  bus  structure  was  effective  in  the  hardware/software 
design.  It  was  also  considered  that  some  features  of  the 
DAIS  software  design,  while  providing  flexibility,  levied 
high  penalties  in  terms  of  excessive  throughput,  overhead 
burdens  and  memory  requirements.  However,  the  point  to  be 
noted  is  not  the  i nef f i ci ences  , but  the  relative  ease  of 
reducing  the  inefficiencies  for  a specific  application.  This' 
was  done  for  the  IDAMST  design  without  destroying  the  basic 
DAIS  design  integrity.  Specification  of  IDAMST  software  was 
accomplished  in  many  cases  where  commonality  of  functions 
existed  between  DAIS  and  IDAMST  by  adapting  the  DAIS  speci- 
fication. Certainly  at  the  B5  software  specification  level 
of  MIL-STD-490,  a high  degree  of  reusable  software  definition 
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through  the  media  of  documentation  does  exist.  Is  is  con- 
sidered that  regardless  of  the  final  software  code  implementa- 
tion, DAIS  as  a model  for  software  specification  of  an  inte- 
grated digital  avionics  system  design  can  be  used  to  facili- 
tate the  software  specification  process.  This  is  especially 
true  if  the  specification  can  be  maintained  in  a common 
higher  order  language  through  progressive  levels  of  detail. 
Reusable  software  at  the  object  code  level  is  not  a tangible 
objective.  However,  reusable  software  at  the  documentation 
level  is  obtainable. 
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ABSTRACT 

Beginning  with  current  conditions  and  practices,  air  transport 
industry  trends  in  avionics  architecture  and  interconnection 
are  sketched.  The  industry's  probable  digital  interconnection 
needs  are  described,  and  future  industry  efforts  toward  pro- 
viding a new  standard  multiplex  bus  are  forecast. 

Some  potential  mutual  benefits  to  government  and  industry 
users  of  MIL-STD-1553 ( ) bus  interfacing  logic  incorporating 

an  ARINC  option  are  identified.  Finally,  additional  industry 
and  government  exploration  of  a common  definition  is 
suggested . 
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1.0  INTRODUCTION 


This  paper  presents  a private  assessment  of  air  trans- 
port avionics  data  bus  requirements,  and  does  not  purport  to 
bear  the  stamp  of  industry  approval.  Also,  it  is  not  pri- 
marily a technical  presentation.  Rather,  it  is  first  an  over- 
view of  current  industry  practice,  trends,  and  needs  in 
avionics  digital  interconnection.  Then,  some  potential 
mutual  benefits  of  a military / indus try  approach  to  providing 
a joint  standard  busing  capability  are  identified.  Finally, 
further  exploration  of  a common  effort  toward  achieving  such 
a busing  concept  is  solicited. 

Because  of  the  number  of  military  avionics  specialists 
attending,  a few  brief  comments  on  the  most  pertinent 
aspects  of  the  commercial  airline  industry  seem  appropriate. 

2.0  INDUSTRY  BACKGROUND 

2.1  Industry  Composition 

The  commercial  airline  industry  includes,  typically,  the 
foreign  and  domestic  scheduled,  nonscheduled  and  supplemental 
carriers.  Their  aircraft  are  quite  varied  in  type,  ranging 
from  the  venerable  DC-3  to  the  747-SP  and  Concorde.  The  U.S. 
fleet  contains  over  2300  aircraft,  and  the  international 
fleet  has  over  6900  planes,  counting  the  U.S.  contingent. 

Also,  of  these  6900  aircraft,  4700  are  jets.  For  survey 
purposes,  the  airline  industry  does  not  include  commuter 
airlines,  business  aviation,  military  air  transport,  or  mili- 
tary command  aircraft.  However,  these  fleets  do  contain 
some  airline-type  equipment  and  may  ultimately  utilize  the 
types  of  busing  systems  addressed  herein. 

2.2  Industry  R&D  Organization 

Even  though  there  are  no  civil  equivalents  for  Depart- 
ment of  Defense  research  coordination,  close  attention  to 
markets  and  technology  keeps  the  industry’s  research  and 
development  efforts  focused  largely  on  similar  activities. 
Also,  much  of  advanced  commercial  avionics  research  is  diffi- 
cult to  separate  from  relevant  military  research;  since  a 
number  of  avionics’  houses  perform  both  functions.  And, 
while  there  are  other  noteworthy  government  and  industry 
efforts,  such  as  those  of  NASA,  SAE , and  RTCA , the  principal 
airline  industry  focus  on  future  avionics  system  architecture 
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and  interconnection  occurs  under  the  aegis  of  Aeronautical 
Radio  Inc.;  perhaps  better  known  as  ARINC. 


2.3  Aeronautical  Radio  Incorporated 

ARINC  is  a corporation  of  domestic  and  foreign  airlines, 
other  air  transport  companies  and  aircraft  manufacturers. 

Its  many  activities  include  the  estab 1 is hmen t of  industry 
avionics  standards.  ARINC  sponsors  the  Airlines  Communica- 
tions Administrative  Council  (ALCAC),  principal  formulator 
of  industry  communications  policy.  One  of  ALCAC's  standing 
committees  is  the  Airlines  Electronic  Engineering  Committee 
(AEEC) . The  establishment  of  avionics  equipment  character- 
istics and  interface  standards  are  AEEC's  principal 
functions . 

Emerging  characteristics  are  coordinated  with  airlines, 
aircraft  manufacturers,  other  aircraft  operators,  military 
services,  and  equipment  manufacturers.  Upon  ratification  by 
the  scheduled  airlines,  ARINC  Characteristics  reflect  an 
industry  opinion  of  requirements,  for  the  guidance  of  equip- 
ment manufacturers,  and  effect  considerable  standardization 
of  equipments.  However,  ARINC  Characteristics  neither  estab- 
lish procurement  requirements,  endorse  any  design,  nor 
restrict  any  purchasers  choice. 

3.0  CURRENT  ARCHITECTURE  AND  INTERCONNECTION 

Previously,  industry  planning  of  architectures  was,  at 
the  overall  systems  level,  dictated  principally  by  technol- 
ogy, changing  regulatory  pressures,  and  the  ever-pervasive 
economic  requirement  of  compatibility  between  equipment 
generations.  Most  of  the  intersubsystem  integration  that 
has  occurred,  has  been  accomplished  in  the  control  and  dis- 
play areas.  The  arrival  of  digitization  is  providing 
industry  its  first  real  opportunity  to  exploit  avionics  sys- 
tems integration. 

Present-day  airliners  employ  a mixture  of  analog,  dis- 
crete, and  digital  signaling.  Most  of  these  circuits  are 
still  analog  or  discrete,  but  the  share  for  digital  busing 
is  large  and  growing  steadily.  Because  of  its  diversity,  it 
is  usually  convenient  to  categorize  this  digital  busing  as: 

• Nonmultiplexable  single-parameter  interconnections 

• Various  nons t andard / pr opr ie t ar y intrasubsystem  buses 
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• Passenger  service  multiplex  systems 

• Standardized  (ARINC  Characteristic)  multiplexed  data  buses. 

The  last  of  the  above  categories  is,  of  course,  the  one 
of  principal  interest.  Of  the  six  standard  ARINC  multiplex 
buses,  one  has  been  accorded  preferred  status:  the  bus  for 

the  ARINC  Characteristic  575  Digital  Air  Data  System.  Its 
preference  derives  from  its  wire  economy  over  ARINC  4 and 
6-wire  buses,  self-clocking  code,  higher  data  rate,  and 
unrestrictive  format.  It  is  more  commonly  referred  to  as 
the  "ARINC  575  bus,"  and  can  be  summarized  as  follows: 

* 

• Serial  data  only 

• Single  twisted  shielded  pair  transmission  medium 

• 11  kbps  bus  rate 

• Ternary  baseband  modulation 

• Simple  bipolar  self-clocking  data  code 

• Broadcast^*)  mode  of  bus  operation 

• Asynchronous  bus  words,  separated  by  (4-bit  min)  nulls 

• 8-bit  parameter  (word)  label  method  of  addressing 

• No  formatting  (frames,  messages,  etc)  above  the  individ- 
ual 32-bit  word  level 

It  is  worth  noting  here  that  the  air  transport  industry 
has  been  actively  studying  multiplexed  half-duplex^)  busing 
since  the  early  1960's.  And,  while  the  more  obvious  advan- 
tages of  such  operation  are  generally  recognized,  the  net 
overall  economic  benefits  of  such  a bus  have  yet  to  be 
demonstrated . 

4.0  INTERGENERATION  EQUIPMENT  COMPATIBILITY 

This  is  probably  an  appropriate  junction  for  addressing 
the  important  subject  of  interchangeability  among  succeeding 
generations  of  avionics  equipment. 


(1) 


See  appendix  for  definition. 
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Currently,  the  avionics  business  is  bounded  by  stable 
requirements,  available  technology,  tight  investment  capital, 
and  highly  competitive  markets.  In  this  context,  the  per- 
formance of  most  of  today's  equipment  leaves  little  oppor- 
tunity for  improvements  unless  it  is  obvious  in  the  proposal 
stage  that  they  will  not  only  repay  their  own  cost,  but  earn 
a return  that  is  competitive  with  that  same  money's  invest- 
ment in  other  airline  company  activities. 

Consequently,  present-day  commercial  avionics  equipment 
is  usually  designed  or  redesigned  for  new  regulatory 
requirements  or  cost  reductions;  not  for  performance  enhance- 
ment per  se.  Certainly,  the  commercial  airliner  application 
provides  nothing  like  the  military's  constant  pressure  for 
mission-performance  improvements.  Of  course,  there  are  often 
improvements  attendant  to  normal  redesign.  However,  if  they 
contribute  unnecessarily  to  cost  they  usually  succumb  to 
economic  realities.  The  digitization  of  commercial  airline 
avionics  is  a good  example  of  this.  Properly  applied,  such 
conversion  has  maintained  or  improved  equipment  performance 
while  effectively  reducing  acquisition  and  ownership  costs. 
Yet,  much  of  the  design  proposed  "just  for  the  sake  of 
digitization"  does  not  survive  the  trade-study  phase. 

It  follows  then,  that  since  much  of  the  industry's 
current  avionics  inventory  is  still  quite  useful  and  repre- 
sents a large  amount  of  very  scarce  capital,  there  is  con- 
siderable reluctance  on  the  part  of  both  airline  operators 
and  equipment  manufacturers  to  introduce  new  technology  that 
is  not  thoroughly  justified;  but  particularly  so,  if  that 
development  is  incompatible  with  sizable  portions  of  the  cur- 
rent inventory.  The  compatibility  of  new  avionics  with 
earlier  generation  equipment  is  therefore  of  great  impor- 
tance, and  breaks  with  backward  compatibility  typically 
occur  only  as  an  adjunct  to  new  airframe  design. 

5.0  CURRENT  RESEARCH  AND  PLANNING 

Burgeoning  avionics  digitization  has  triggered  new  air- 
line interest  in  the  planning  of  future  digital  avionics 
systems  and  components.  To  formulate  future  systems  archi- 
tecture and  interconnection  guidance  for  airframe  and  equip- 
ment manufacturers,  AEEC  has  established  the  Systems 
Architecture  and  Interface  (SAI)  Subcommittee.  This  sub- 
committee has  met  quarterly  since  October  1975.  Approxi- 
mately 10  airlines,  5 airframe  manufacturers,  and  20 
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avionics  houses  form  its  international  membership.  Cur- 
rently, the  subcommittee  is  in  the  process  of: 

• Identifying  avionics  system  requirements 
•Establishing  evaluation  criteria 
•Selecting  baseline  architectural  concepts 

• Investigating  partitioning  methodology 
•Partitioning  representative  candidate  systems 

• Performing  preliminary  evaluations  of  the  above 

The  baseline  aircraft  for  future  avionics  system  con- 
cepts range  from  near-term  next  generation  aircraft  with 
conventional  airframes  to  advanced  technology  aircraft  with 
fly-by-wire  controls.  The  present  emphasis  is  on  near-term 
candidate  systems  which  typically  include  such  concepts  as 
electronic  engine  control,  autoland,  digital  flight  instru- 


ments, and  sensors  with  digital  outputs. 


In  the  digital  busing  domain,  the  subcommittee  has 
selected  a multiplexed  broadcast  bus  as  one  component  of  its 
architecture  development  baseline  system;  since  it  is  gen- 
erally recognized  that,  due  to  economic  constraints,  a near- 
term  new  aircraft  could  not  effectively  incorporate  a 
half-duplex  bus  structure.  However,  half-duplex  busing  is 
being  studied  for  comparison  with  contemporary  buses,  with 


expectations  of  future  airframe  incorporation.  The 
MIL-STD- 1 553A  bus  is,  of  course,  receiving  specific  atten- 
tion. It  is  expected  that  the  current  effort  will  result  in 
industry  recommendations/guidelines  in  several  of  the  follow- 
ing areas: 

•Architectural  practices 
• Equipment/system  characteristics 


• Internal  and  external  system 

• Data  bus  characteristics 


interface  characteristics 


6.0  BROADCAST  VS  HALF-DUPLEX  OPERATION 

Current  industry  planning  of  avionics  system  architec- 
ture and  interconnection  is  focused  on  flight  guidance/ 
control  system  architecture  and  interface  definition.  For 
interfacing  purposes,  two  existing  bus  standards,  ARINC  575 
and  MIL-STD-1553A,  have  received  special  attention.  Perti- 
nent characteristics  of  the  ARINC  575  bus  were  summarized  in 
section  3.0. 

Figure  1 shows  a model  flight  guidance /control  system, 
with  the  ARINC  575  bus  as  its  digital  interconnection  medium. 
It  is  generally  believed  that  such  a system  is  simple  but 
practical,  and  could  be  implemented  in  air  transport  aircraft 
in  the  very  near  future.  Also,  this  model  can  be  used  as  a 
basis  for  evaluating  the  benefits  of  multiplexed  half-duplex 
busing . 

Figure  2 shows  the  same  flight  guidance/control  system 
model  with  MIL-STD-1553A  busing  as  the  interconnection 
medium.  Choice  of  the  number  of  buses  (five  in  the  system 
under  consideration)  is  a compromise,  based  on  system  integ- 
rity, growth,  etc. 

Table  1 compares  the  two  interconnection  techniques. 

For  the  model  system,  the  1553A  interconnect  requires  less 
wire  and  offers  more  system  configuration  flexibility.  On 
the  other  hand,  the  broadcast  bus  approach  is  superior  in  its 
simplicity  of  bus  control  implementation;  and  unless  very  low 
cost  1553A  bus  interfacing  hardware  is  available,  the  broad- 
cast solution  is  the  more  economical  of  the  two. 
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Fig-ir®  1.  Guidance/Control  System  Interconnect  (Broadcast  Bus). 
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Table  1.  Comparison  of  Interconnection  Concepts. 


BROADCAST 

MULTIPLEX 

ARINC  BUS  STANDARD 

MORE  FLEXIBILITY 

EXISTS 

BETTER  FAULT 

MAXIMUM  FUNCTIONAL 

ISOLATION 

ISOLATION 

MINIMUM  WIRE 

SIGNIFICANT  WIRING 
REDUCTION 

COST  DEPENDENT  ON 
LSI 

RELIABILITY/ ISOLATION 
CONSIDERATIONS  MORE 
SIGNIFICANT 

BOTH  OFFER  SIGNIFICANT 

EQUIPMENT  COST  REDUCTIONS. 

7.0  INTERCONNECTION  TRENDS 

The  industry's  strong  interest  in  effective  avionics 
busing  is  evident  in  its  renewed  efforts  to  improve  busing 
application  along  with  new  system  architecture  development. 

In  particular,  there  will  be  a continued  effort  to  evolve 
data  bus  concepts  in  support  of  firm  projected  architectural 
concepts  and  modest  operational  growth.  These  efforts  are 
currently  aimed  at  determining  the  impact  of  busing  on 
architecture  and  cost-of-ownership , and  projecting  early 
1980's  busing  requirements. 

As  mentioned  before,  the  SAI  subcommittee  has  chosen  a 
serial,  single  twisted  shielded  pair,  broadcast  mux  bus  for 
its  current  architectural  candidates.  That  decision  reflects 
the  attitude  that  whether  the  bus  is  half-duplex  or  broad- 
cast does  not  significantly  impede  the  more  immediate  effort 
of  architectural  development.  Nonetheless,  the  subcommittee 
is  continuing  its  comparison  of  half-duplex  and  broadcast 
modes  of  multiplex  bus  operation,  to  establish  application 
requirements  and  operational  and  economic  benefits. 

Industry  agreement  on  the  following  benefits  of  a half-duplex 
mux  bus  appears  to  be  coalescing: 
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• Reduced  aircraft  wiring 

• Improved  maintainability 

• Reduced  cost  of  system  recovery/reversion  capability 

• Reductions  in  system  reconfiguration  costs 

However,  in  the  commercial  air  transport  context,  such 
a bus  does  not  yet: 

• Provide  maximum  functional  isolation  in  the  interests  of 
system  integrity 

• Offer  an  industry  busing  standard  where  none  now  exists 

• Demonstrate  sufficient  sure  or  proven  economic  advantage 
over  broadcast  busing,  such  that  it  would  pay  to  go 
half-duplex  today  instead  of  employing  a compatible 
variation  of  the  ARINC  575  bus 

Since  the  industry  can  afford  improved  equipment/system 
performance  only  if  such  enhancements  increase  profits  or 
respond  to  mandated  requirements,  substantial  investment  in 
a quantum  jump  of  capacity/capability  for  functional  diversi- 
fication or  growth  should  not  be  expected.  Consequently,  one 
should  not  anticipate  significant  implementation  of  half- 
duplex busing  in  the  next  generation  airliner.  In  fact,  a 
higher  speed  ARINC-57 5-type  bus  currently  seems  the  strong- 
est contender  for  near-term  next  generation  implementation 
of  an  improved/new  industry  standard  A concurrent 
increased  exploitation  of  digital  technology,  especially  LSI, 
is  also  anticipated,  but  prim4rily  for  cost  reduction 
purposes . 

Other  industry  activities,  in  support  of  providing  an 
improved  standard  bus,  seem  predictable.  Those  activities 
include : 

• Identification  of  requirements  for  intermediate  (next) 
generation  bus/terminal  interfacing  logic  and  bus  modems 

• Study  of  thin/thick  film  hybrid  and  LSI  implementation  of 
bus/terminal  interfacing  logic  and  bus  modems 

• ARINC  specification-partitioning  and  generation  for  any 
new  bus  interfacing  logic,  bus  controllers,  or  bus  modems 
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In  a late  1980's  airframe,  standardized  intersubsystem 
half-duplex  bus  multiplexing  may  well  be  a reality.  Fur- 
thermore, it  may  even  be  implemented  with  LSI  bus  interfac- 
ing hardware;  depending  on  production  technology,  complexity 
requirements,  and  standardization  market  opportunities. 

8.0  ANTICIPATED  INDUSTRY  REQUIREMENTS 

As  one  may  have  already  perceived,  industry  consensus  on 
future  air  transport  multiplexed  serial  digital  data  bus 
characteristics  has  yet  to  crystallize.  However,  certain 
requirements  for  near-term  next  generation  aircraft  appear 
to  be  emerging;  and  the  more  interesting  ones  are: 

• Availability  of  broadcast  mode  of  bus  generation 

• Minimize  maintenance  of  system  configuration  data  in  cen- 

tral bus  controllers  (thus,  system  implementation  changes 
have  minimal  impact  on  controller  programming.  Examples 
of  parameters  that  might  better  be  left  to  terminal  con- 
trol are:  participating  receiver  designation  for  each 

message,  and  message  length). 

• Word  length  of  32  bits  total 

• 8-bit  parameter  (word)  label  form  of  addressing 

9.0  MUTUAL  MILITARY  INDUSTRY  BENEFITS 

There  appear  to  be  some  potentially  substantial  mutual 
benefits  to  military,  government,  and  industry  users  of  LSI 
implementations  of  MIL-STD- 1 553 ( ) bus  interfacing  logic 

incorporating  an  ARINC  bus  option.  These  benefits  include: 

• Lower  avionics  equipment  prices,  due  to  higher  production 
volumes 

• Better  equipment  availability,  due  to  increased  avionics 
market  commonality 


• Lower  aircraft  acquisition  costs,  due  to  greater  compati- 
bility between  off-the-shelf  aircraft  systems  and  avionics 
equipment 

• Lower  maintenance  costs  due  to  increased  commonality  of 
avionics  systems  and  equipment. 
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To  whatever  extent  appropriate,  these  benefits  would 
apply  to  the  use  of  off-the-shelf  military  or  commercial 
air  transport  avionics  equipment  in: 

• Military  and  government  air  transport  -raft,  especially 
those  with  civil-origin  airframes 

• Military  and  government  command  aircraft  with  business 
aviation  origins 

• Applicable  special  military  and  federal  aircraft  such  as 
weather,  patrol,  rescue  and  airborne  command  post  air- 
craft; again,  with  airframes  of  civil  origin. 

10.0  CONCLUSIONS 

Assessment  of  the  status  of  military  and  air  transport 
multiplex  bus  development  would  seem  to  indicate  that  there 
could  b €;  considerable  mutual  benefit  if  there  were  a common 
avionics  bus  solution  that  was  acceptable  to  both. 

Even  though  industry's  bus  requirements  are  not  yet 
crystallized,  their  trend  is  discernible.  And  there  appears 
to  be  more  common  ground  than  not,  between  military  and 
industry  avionics  bus  needs.  Also,  while  commercial  applica- 
tion timing  seems  to  be  lagging  the  military's,  availability 
of  an  appropriate  M1L-STD-1553 ( ) implementation  could  very 

well  accelerate  industry's  schedule. 

Finally,  the  air  transport  industry  would  welcome 
further  joint  exploration  of  common  avionics  multiplex  bus 
application  and  benefits. 
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Simplex  mode:  One-way  communication  between  one  transmitter 

and  one  receiver. 


Broadcast  mode:  One-way  communication  between  one  trans- 

mitter and  two  or  more  potential  receivers. 


Half-duplex  mode:  Two-way  communication  between  two 

transmitter/receiver  terminals,  conducted  via  the  alterna- 
tion of  simplex  mode  operation  in  each  direction. 
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ABSTRACT 


Within  a system,  such  as  a radar  or  an  ECM  set,  there  exists  a 
need  for  a simple  high  data  rate  multiplex  bus.  The  requirements  on 
this  bus  differ  from  the  requirements  on  a typical  serial  multiplex  bus. 
Major  differences  include  data  transmission  speed,  transmission  line 
lengths,  electrical  noise,  and  driver  receiver  design. 

1.  GENERAL  REQUIREMENTS 

The  general  requirements  that  favor  parallel  bus  over  serial  bus 
structures  are  data  transmission  speed,  transmission  line  length, 
transmission  line  noise,  and  driver /receiver  design. 

Intrasystem  data  transmission  speeds  are  usually  higher  than  inter- 
system transmission  speeds.  Intersystem  data  transmissions  contain 
mostly  mode  commands,  status  checks,  and  a final  computational  pro- 
duct such  as  a target  or  threat  report.  Intrasystem  data  transmissions 
contain  all  of  the  above  plus  built-in  test,  fault-isolation  test,  calibra- 
tion checks,  and  all  input  and  intermediate  data  transmissions  needed 
to  arrive  at  the  final  computational  product. 

Transmission  line  lengths  need  be  only  several  feet  in  length  as 
compared  with  over  30  feet  in  some  serial  multiplex  bus  applications. 
With  this  shorter  length  it  is  more  practical  to  use  a parallel  bus  struc- 
ture. Control  signal  propagation  delays  are  smaller  and  transmission 
line  termination  problems  are  reduced  as  compared  to  a serial  multi- 
plex bus. 


Intrasystem  transmissions  have  less  electrical  noise.  This  is  be- 
cause the  system  designer  has  better  control  over  the  grounding  system, 
and  the  transmissions  cables  are  short  and  do  not  pickup  much  elec- 
trical noise.  By  minimizing  common  mode  noise,  the  bus  design  need 
not  use  transformer  isolators.  By  minimizing  difference  mode  noise 
the  bus  design  can  use  standard  M38510/10404  receivers  and  either 
M38510/10403  or  M38510/10405  drivers,  which  makes  a much  simpler 
bus  interface. 

2.  GENERAL  DESCRIPTIONS 

The  Digibus  is  a parallel  bus  with  tristate  differential  drivers  and 
receivers.  It  has  a data  width  of  8 bits  expandable  in  integer  multiples 
of  8 bits.  It  has,  in  addition  to  the  data  bits,  separate  control  bits  also 
with  differential  drivers  and  receivers. 

The  entire  Digibus  is  under  the  control  of  the  computer,  and  each 
peripheral  unit  must  be  capable  of  responding  to  the  Digibus  timing  which 
is  controlled  by  the  computer.  The  peripheral  unit  interfaces  with  the 
Digibus  byway  of  the  DIU  (Digibus  Interface  Unit).  A typical  Digibus 
System  is  shown  in  Figure  1. 

Figure  2 shows  two  systems,  that  use  Digibus,  integrated  with  a 
serial  multiplex  bus  into  a Central  Management  computer.  The  Central 
Management  computer  transmits  and  receives  over  the  serial  multiplex 
bus  mode  controls,  status  information,  and  final  reports  (processed 
data).  The  system  computer  transmits  and  receives  over  the  Digibus 
data  required  for  the  operation  of  the  system. 

3.  SPECIFIC  DESCRIPTION 

The  Digibus  has  been  used  on  several  Westinghouse  system.  The 
description  of  one  si’.ch  application  follows. 

3.  1 BUS  ORGANIZATION 

The  Westinghouse  ECM  set  interface  control  is  bus-oriented  (figure 
3).  All  peripheral  devices  (functional  modules)  controlled  by  the  Mini- 
computer are  connected  via  digibus  interface  units  to  the  Minicomputer 
I/O  over  a bidirectional  8-bit  digibus.  This  bus  has  multiple,  identical, 
interface  connectors.  Thus,  digibus  organization  is  independent  of 
peripheral  devices.  A system  in  which  a peripheral  device  is  unplugged 
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TO  FUNCTIONAL 
MODULE 


Figure  3.  Westinghouse  ECM  Set  Interface  Control  Bus  Orientation 

from  one  bus  connector  and  plugged  into  another  would  continue  to  op- 
erate without  requiring  any  changes  in  either  hardware  or  software. 

The  Minicomputer  is  the  master  controller  of  the  digibus,  since 
all  data  transfers  in  either  direction  are  initiated  and  monitored  by  the 
Minicomputer.  The  Minicomputer  issues  a command  and  then  com- 
mands the  data  transfer. 

The  digibus  organization  permits  the  Minicomputer  to  take  inventory 
of  the  peripheral  devices  on  the  bus.  Each  device  is  queried  as  to  its 
status  and  characteristics.  Once  the  status  and  characteristic  inven- 
tories are  prepared,  the  system  may  respond  to  threats  in  accordance 
with  its  peripheral  inventory.  Peripherals  may  be  added  or  deleted 
from  the  pod  configuration  as  the  mission  requires.  No  new  software 
need  be  developed  as  long  as  the  existing  software  can  handle  the  de- 
vices in  the  inventory. 
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3.  2 ADDRESSING  AND  PROGRAMMING 


Up  to  16  peripheral  devices  may  be  controlled  by  the  bus.  Each  is 
addressed  by  a 4-bit  address  code.  The  address  code  is  determined 
by  the  peripheral  device,  not  the  bus  interface  connector.  This  per- 
mits the  system  to  be  configured  without  hardware  or  software  changes, 
even  when  the  configuration  is  changed  to  meet  mission  requirements. 
When  the  computer  specifies  an  address,  the  peripheral  device  with 
that  address  code  responds  with  either  an  input  or  output  of  data.  The 
computer  instruction  word  contains  the  address  of  the  peripheral  device 
selected  plus  a 3 -bit  command  code. 

The  symbolic  code  of  an  output  word  is: 

O AO,  SELC 

where  O is  07g  the  mnemonic  for  the  output  AO  is  the  register  from 
which  data  is  to  be  transferred  (any  general  purpose  register  may  be 
used).  The  SELC  is  a 7-bit  select  code.  The  binary  code  of  the  same 
output  word  is 


07 


AO 


O 


SELC 


16 


13  12  10  9 8 


where  AO  is  the  register  from  which  data  is  to  be  transferred  (any  gen- 
eral purpose  register  may  be  used). 

To  effect  an  output  from  the  processor  on  the  digibus,  two  signals 
originating  in  the  Minicomputer  I/O  are  required:  COMMAND  STROBE 
and  DATA  STROBE.  First,  an  8-bit  output  command  is  formed  in  con- 
junction with  a COMMAND  STROBE. 


Computer  Command  Word: 

DB  8 DB  7 DB  6 DB  5 DB  4 DB  3 DB  2 DB  1 


0 


SELC 


Several  micorseconds  later,  data  appears  on  the  8 -bit  bus  in  coor- 
dination with  a DATA  STROBE. 

Data  Word: 

DB  8 DB  7 DB  6 DB  5 DB  4 DB  3 DB  2 DB  1 

] 


DATA 


The  symbolic  code  of  an  input  word  is: 

I AO,  SELC 

where  I is  06g,  the  mnemonic  for  the  input  AO  is  the  register  to  which 
the  data  is  to  be  transferred  (any  general  purpose  register  may  be 
used),  and  SELC  is  a 7-bit  select  code.  The  binary  code  of  the  same 
input  word  is 


06 

AO 

O 

SELC 

16 

13 

12 

10 

9 8 1 

where  the  data  is  put  into  the  lease  significant  bits  of  AO. 

The  input  instruction  in  the  computer  results  in  two  different  opera- 
tions on  the  bus.  First,  an  8-bit  input  command  is  formed  in  conjunc- 
tion with  a COMMAND  STROBE. 

Computer  Command  Word: 

DB  8 DB  7 DB  6 DB  7 DB  4 DB  3 DB  2 DB  1 

1 SELC 


The  command  word  directs  the  instruction  to  one  of  16  different 
terminal  codes  (table  1).  Note  that  for  the  bus-tie  unit,  the  receiver/ 
processor,  and  the  Control /Interface,  these  are  fixed  terminal  codes 
associated  with  their  commands.  However,  in  the  case  of  the  trans- 
mitter modules,  there  is  no  direct  assignment  of  terminal  codes  to  the 
equipment.  Therefore,  system  commands  must  be  directed  to  termi- 
nals, not  to  equipment. 

Several  microseconds  after  generating  the  command  word,  an  En- 
able is  activated  in  the  computer  and  fed  via  the  digibus  to  the  module 
being  commanded.  The  Enable  signal  transfers  an  8-bit  data  word  from 
the  commanded  unit  on  to  the  digibus.  The  data  word  format  is  given 
below  and  is  applicable  to  both  input  and  output  words. 

DB  8 DB  7 DB  6 DB  5 DB  4 DB  3 DB  2 DB  1 

DATA 
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TABLE  1 

DIGIBUS  STANDARD  TERMINAL  CODES 


Terminal  Codes  Description 

0000 

(Future  Test  Equipment) 

0001 

Interface  and  Control  Data 

0010 

(Spare) 

0011 

(Spare) 

0100 

Bus  Tie  Unit 

0101 

Printer 

0110 

Receiver /Processor 

0111 

t 

" NOTE: 

1000 

Left  i 

1001 

Right  > Leading  Modules 

Terminal  codes 

1010 

Bottom  ' 

used  in  transmit 

1011 

External  Test  Connectors 

modules 

1100 

Left  | 

1 

1101 

Right  j 

2 

1110 

Bottom  * Trailing  Modules 

3 

mi 

^lalf  Canister 

4 

5 

Two  standard 

interfaces  are  used  on  the  digibus, 

, Where  there  are 

very  few  data  registers  to  control,  the  DESIGNATOR  CODE  (table  2)  is 
used  as  a direct  reference  for  input  or  output  of  up  to  eight  registers. 

TABLE  2 

DIGIBUS  STANDARD  DESIGNATOR  CODES 


Designator  Codes 

000 

C01 

010 

011 

100 

101 

110 

111 


Desc  ription 
Status 

Major  address 
Minor  address 
Data,  increment 
Data,  nonincrement 
Power 

Who  are  you? 
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Input  and  output  under  the  designator  codes  simply  reference  various 
registers  at  these  interfaces.  Further,  where  the  interface  is  a com- 
puter to  computer  interface,  these  registers  are  used  as  either  inter- 
face flag  control  or  as  data  buffers  for  asynchronous  interfaces.  The 
receiver /processor  and  bus-tie  are  very  similar  examples  of  this. 

For  digibus  interfaces  where  more  than  eight  registers  are  involved, 
a different  addressing  scheme  is  used.  In  order  to  provide  for  flexible 
control,  a sublevel  of  addressing  is  used.  In  each  of  these  data  areas 
(terminal  codes),  there  is  a major  and  a minor  address  register  (8  bits 
each)  for  data  control.  The  designator  code  loads  data  first  into  the 
major  address  register  (code^l)  followed  by  data  for  the  minor  address 
register  (code=2).  With  these  two  registers  directly  under  digibus  con- 
trol, 16  bits  of  sublevel  addressing  is  possible  for  subsequent  data 
transfer. 

Each  data  word  is  assigned  a unique  major  and  minor  address.  The 
only  difference  between  the  two  registers  is  that  the  minor  address  can 
be  automatically  incremented  with  data  transfers  for  successive  loading 
of  large  data  blocks. 

3.  3 INTERFACE  UNITS 

The  basic  design  of  the  digibus  system  includes  digital  interface 
units  which  are  connected  to  the  8-bit  bi-directional  digibus  and  the 
peripheral  devices.  All  communications  to  the  computer  are  through 
these  interface  units.  These  interface  units  must  be  capable  of  re- 
sponding within  the  allotted  time  since  the  entire  digibus  and  digital  in- 
terface system  is  under  Minicomputer  control. 

The  timing  required  to  provide  proper  data  transmission  to  and 
from  the  Westinghouse  Minicomputer  is  shown  in  figures  4 and  5. 

The  basic  transfer  operation  includes  the  transfer  of  an  8-bit  address 
code  to  each  of  the  digibus  interface  units.  Each  digibus  unit  compares 
the  received  address  code  with  the  code  of  the  terminal  location  in  the 
pod  (DB  4,  5,  6,  7)  to  which  the  unit  is  connected.  The  peripheral  de- 
vice with  the  proper  code  (as  compared  by  the  digibus  interface  unit) 
will  then  receive  one  of  the  sub-address  command  codes. 

The  second  part  of  the  transfer  is  an  8-bit  data  word  received  either 
by  the  peripheral  device  (output)  or  sent  from  the  peripheral  device 
(input). 


r* 


~ ^ 


ADDRESS  & COMMAND 
IN/OUT  ^ 


I I I I I I I | | 

DATA 


£ 


X 


INCREMENT  350  ntec 
BUS  TIMING 


COMMAND  STROBE 


ADDR  I.  ADDR  2.  ADDR  3 

COMMAND  CODE  WILL  BE  GOOD  FOR  A 
MIN  OF  1.33*tsec 


IN/OUT  TIMING  SAME  AS  ADDR  1 ADDR  2 
ADDR  3 

COMMAND  TIMING  FOR  OPTIONS  1 & 2 
ARE  THE  SAME  AS  OUTPUT  COMMANDS 


Figure  4.  Data  Transfer  Timing  From  Digibus  Unit  to  Computer 

Interface  signals  are  identified  in  figure  6 and  are  described  in  the 
following  subparagraphs. 


a*  i^g^puter- to -Interface  Signals  - These  signals  are  connected 
from  the  Minicomputer  Input/Output  (I/O)  to  the  digibus  interface  unit 
(figure  6). 


DB01,  DB01  through  DB08,  DB08 

These  lines  form  the  bidirectional  8 -bit  information  path  between  the 
computer  and  aU  other  units. 

COMMAND  STROBE,  COMMAND  STROBE 

This  signal  is  used  to  enter  commands  from  the  computer  into  the 
digibus  interface  units. 


DATA  STROBE,  DATA  STROBE 
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I I I I I I I I I 


INCREMENT  350  n»#c 


ADDRESS  & COMMMAND  IN/OUT 


DATA  BUS  TIMING 


COMMAND  STROBE 


DATA  STROBE  OUT  TAKE  DATA  AT  POINT  C 


GOOD  COMMAND 


ADDR  1.  ADDR  2.  ADDR  3 COMMAND  CODE  WILL 
BE  GOOD  FOR  A MIN 
of  1 33  fisec 


IN/OUT  (GOOD  AT  THE  SAME  TIME  AS  ADDR  1 
ADDR  2.  ADDR  3» 


OPTION  1 (CONNECT  VALID  LINE  TO  ZZ) 


COMMAND  SELECTED  (Cn  C_»  (ALL  OTHER 

U ' COMMANDS  REMAIN  HICiHl 
NO  SPIKING  ON  COMMAND 
LINES 


OPTION  2 (CONNECT  ZZ  TO  GND) 


(VALID  LINE  AND  ZZ  NOT  CONNECTEDI 


FHOM  START  OF  VALID  LINE 

FOR  A MIN  OF  1 33/Llsi*c 

SPIKING  CAN  OCCUR  PRIOR  TO  VALID  LINE 


Figure  5.  Data  Transfer  Timing  From  Computer  to  Digibus  Unit 

This  signal  is  used  to  inform  the  selected  unit  that  data  from  the 
computer  is  now  on  the  BUS  lines. 

INPUT  ENABLE,  INPUT  ENABLE 


This  signal  is  used  to  define  the  time  that  the  selected  unit  must  have 
its  data  on  the  digibus  lines. 

b.  Interface -to-Peripheral  Signals  - The  following  signals  are  con- 
trol signals  supplied  by  the  digibus  interface  unit  to  the  peripheral  de- 


IN  /OUT 


TRANSMIT  ENABLE 


1 


DB  1-8 


DATA  STROBE 


INTERFACE 
UNIT  TO 
PERIPHERAL 


DIGIBUS 


INTERFACE 


DATA  STROBE  OUT 


DIN  1-8 


IN/OUT 


OOL  1-8 


VALID  LINE 


DESIGNATOR  CODE  (0-2) 


DESIGNATOR  ADDRESS 
(1-8) 


STANDBY  POWER 


TERMINAL 
CODE  (1-4) 

Figure  6.  Peripheral  Interface  Signals 


73-09  20-VA-26-1 


A 


This  signal  defines  the  direction  of  data  flow  (0  means  DATA  to 
PERIPHERAL,  1 means  DATA  from  PERIPHERAL).  The  signal  is  only 
valid  during  an  I/O  cycle. 

DATA  STROBE  OUT 

This  signal,  when  data  is  transferred  to  the  peripheral  from  the 
processor,  is  used  to  enter  data  into  the  peripheral.  Data  is  entered 
at  the  trailing  edge  of  the  signed. 

TRANSMIT  ENABLE 

This  signal,  when  data  is  transferred  to  the  computer  from  the  pe- 
ripheral, is  used  to  indicate  data  is  being  transmitted  to  the  computer. 
The  peripheral  device  must  hold  its  data  constant  for  the  duration  of 
the  signal. 


STANDBY  PWR 


This  signal  is  generated  inside  the  digibus  interface  unit  be  decoding 
of  command  5.  When  PWR  is  high,  standby  power  should  be  "on"  in  the 
peripheral  unit. 

VALID  LINE 

This  signal  defines  an  I/O  cycle.  The  command  codes  associated 
with  ADDRl,  ADDR2,  and  ADDR3  as  well  as  IN/OUT  should  only  be  con- 
sidered correct  during  the  VALID  signal. 

DIN  1 THROUGH  DIN  8 

These  eight  lines  are  the  data  lines  from  the  digibus  interface  unit 
to  the  remainder  of  the  peripheral  device.  Data  is  taken  from  these 
lines  at  the  trailing  edge  of  the  DATA  STROBE  OUT  signal. 

DOL  1 THROUGH  DOL  8 

These  eight  lines  are  the  data  lines  to  the  digibus  interface  unit  from 
the  remainder  of  the  peripheral  device.  Peripheral  device  data  should 
be  stable  on  these  lines  for  the  duration  of  the  TRANSMIT  ENABLE 
signal. 


TERMINAL  CODE  (1-4) 


The  Terminal  Codes  shown  in  table  1 are  specified  on  these  4 lines. 
This  provides  a unique  address  to  every  peripheral  (Digibus  Interface 
Unit)  in  the  system. 


DESIGNATOR  CODE 

See  figure  7 for  definition. 

3.4  INPUT /OUTPUT 

The  Input/Output  (I/O)  section  of  the  Minicomputer  functions  as  the 
interface  between  the  common  digibus  and  the  processing  section  of  the 
computer.  The  I/O  is  entirely  under  program  control,  where  the  con- 
tents of  the  registers  specified  by  the  AO  field  in  the  input /output  in- 
struction are  placed  onto  or  read  from  the  digibus. 

The  I/O  is  comprised  of  the  tristate  line  drivers,  receivers,  count- 
ers, and  decoders  which  generate  the  bus  commands  and  timing  signalf 
required  by  the  pod  data  bus. 

The  bus  line  drivers  are  tristate  device,  and  the  receivers  are  dual 
differential  line  units.  The  line  receivers  are  especially  designed  to 
receive  differential  digital  data  from  transmission  lines. 

To  place  information  on  the  bus,  line  transmitters  are  switched 
from  their  high  impedance  state  to  a low  impedance  state.  Line  trans- 
mitter switching  signals  are  generated  by  a counter  and  decoder  located 
on  the  I/O  board.  When  in  the  low-impedance  state,  the  line  transmit- 
ters have  the  ability  to  receive  or  supply  (sink  or  source)  approximately 
40  milliamperes.  With  the  line  transmitters  enabled,  a binary  one 
(approximately  4 volts)  is  on  the  bus;  a binary  zero  is  approximately 
zero  volts.  With  the  line  transmitter  in  the  high-impedance  state,  the 
driver  leakage  current  is  in  the  microampere  range,  thereby  allowing 
many  transmitters  to  be  connected  to  the  bus.  Because  the  receivers 
operate  in  the  differential  mode,  data  transmissions  are  relatively  in- 
sensitive to  common  mode  noise. 

The  line  transmitters  and  receivers  for  each  of  the  eight  bits  are 
connected  to  the  digibus  as  shown  in  figure  8. 


Band  0 & E 1C  Data 


ENABLE 
SIGNAL  ' 


READ  ENABLE 


MILLICOMPUTER 
I/O  BUS 


DUAL 

DIFFERENTIAL 
LINE  RECEIVER 


TRI  STATE  LINE 
TRANSMITTER 


BITSTO  DIGIBUS 


74-0339-VA-6 


The  purpose  of  the  30-ohm  resistors  is  to  minimize  standing  waves 
on  the  bus  and  to  provide  an  impedance  match.  The  IK  resistois  are 
"pullup"  resistors  to  +5  volts.  Using  the  IK  resistors  improves  the 
rise  and  fall  times  of  the  signal  on  the  bus  and  increases  the  pulse  am- 
plitude to  +4  volts.  The  value  of  the  "pullup"  resistance  and  series 
resistance  is  a function  of  the  bus  length  and  type,  the  characteristics 
of  the  line  transmitters  and  receivers.  In  general,  these  values  are 
selected  for  each  application. 


The  digibus  is  constructed  of  flexible  cable,  with  a characteristic 
impedance  of  approximately  120  ohms.  The  cable  length  depends  upon 
the  pod  configuration;  maximum  length  is  approximately  30  feet  long. 
Twelve  modules  (peripherical  units)  are  connected  to  the  bus.  Sixteen 
such  modules  can  be  connected  to  the  bus.  The  number  is  limited  by 
the  format  address  word  rather  than  any  electrical  design  restriction 
of  the  receiver  /drivers  or  bus. 
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ADDENDUM 

MULTIPLEX  DATA  BUS  CONFERENCE 
3-5  Nov  1976 
Dayton,  Ohio 


The  following  papers  were  submitted  for  publi- 
cation in  the  Proceedings.  3ecause  of  insufficient 
conference  time,  these  papers  will  only  be  presented 
if  an  author  is  absent. 
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ABSTRACT 


This  paper  describes  the  results  of  work  performed  by 
SCI  for  the  Air  Force  Avionics  Laboratory  relative  to  the 
design,  analysis,  and  specification  of  an  advanced  inte- 
grated digital  avionics  information  system  for  the  Integra- 
ted Digital  Avionics  for  a Medium  Short-take-of f-and-landing 
Transport  (IDAMST). 

A recommended  avionics  suite  is  presented  which  is 
based  on  an  analysis  of  operational  requirements.  The 
recommended  suite  includes  integrated  cockpit  controls  and 
displays,  three  advanced  airborne  digital  computers,  a 
mass  memory  and  22  other  avionics  subsystems.  A multiplex 
system  design  based  on  an  analysis  of  signal  flow  require- 
ments imposed  by  the  avionics  suite  is  then  described.  The 
multiplex  system  design  employs  standard  Remote  Terminals 
(RTs)  and  Bus  Control  Interface  Units  (BCIUs)  being  developed 
for  the  Digital  Avionics  Information  System  (DAIS)  program. 

Interface  requirements  associated  with  integrating  the 
avionics  subsystems  to  the  multiplex  system  were  analyzed 
and  specified  on  the  basis  of  the  best  available  data. 

* This  work  was  sponsored  by  the  AF  Avionics  Laboratory 
under  Contract  No.  F336l 5-75-D-1125 • 


introduction 


Through  the  use  of  multiplex  data  bus  technique  and 
hardware  developed  under  the  Air  Force's  Digital  Avionics 
Information  System  (DAIS)  program,  the  integration  of  the 
Advanced  Medium  Short-take-of f-and-landi ng  Transport  (AMST) 
avionics  has  been  shown  to  yield  significant  benefits.  Such 
an  integrated  system  has  been  named  the  Integrated  Digital 
Avionics  for  a Medium  Short-take-of f-and  landing  Transport 
(IDAMST).  A study  of  IDAMST  at  the  Air  Force  Avionics 
Laboratory  (AFAL)  has  shown  one  of  the  major  advantages  of 
IDAMST  is  that  it  permits  the  entire  aircraft  to  be  operated 
by  only  a two-man  crew  consisting  of  pilot  and  co-pilot.  By 
integrating  the  functions  normally  performed  by  a navigator 
into  the  cockpit  controls  and  displays,  the  need  for  a 
navigator  station  such  as  that  found  in  a C-130  aircraft  has 
been  completely  eliminated.  In  addition,  a large  part  of  the 
operational  software,  support  software,  and  hardware  equip- 
ment developed  as  a part  of  the  DAIS  hot  bench  can  be  direct- 
ly used  in  the  IDAMST  resulting  in  significant  savings. 

This  paper  addresses  the  design  of  the  multiplex  system 
which  makes  IDAMST  a viable  concept.  The  design  process 
begins  with  the  definition  of  an  avionics  suite,  and  is 
culminated  in  the  generation  of  multiplex  system  and  avionics 
subsystem  interface  specifications. 

RESULTS 


In  the  beginning  of  the  IDAMST  multiplex  study,  avionics 
requirements  were  defined  from  consideration  of  the  following: 

° Operational  Requirements  (mission  requirements) 

- Tactical  Air  Drop 

- Low  Altitude  Parachute  Extraction 

- Assault  Landing 

- Single  Ship  Air-Land  Cargo  Delivery  and 
Deployment  Missions 

° Military  Requirements 
° Civil  Regulations 
° Flight  Safety 

After  analyzing  all  the  present  and  future  requirements,  an 
avionics  suite  described  in  Table  1 was  generated  by  AFAL, 
and  it  forms  a basis  for  the  subsequent  study  and  analysis. 
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Table  1.  IDAMST  BASELINE  AVIONICS  SUITE 


S . NO . Subsystem  Designation  Qty . 


1 

Radar  Set 

AN / APQ-122 ( V ) 5 

1 

2 

Radar  Altimeter 

AN/APN-I9I4  (V  ) 

2 

3 

AHARS 

A/A2l*G-26B 

1 

h 

INS 

CAROUSEL  IV-A 

1 

5 

OMEGA 

AN /ARN-XXX 

1 

6 

Public  Address  System 

AN/AIC-13 

1 

7 

HF/SSB  Radio 

AN / ARC-123 ( V ) 

1 

8 

VHF/FM  Radio 

FM-622A 

1 

9 

VHF/AM  Radio 

AN /ARC-11 5R 

1 

10 

INTERCOM 

AN/AIC-18 

1 

11 

Speech  Security  Set 

TSEC/KY-58 

1 

12 

IFF  Set 

AN / APX-101 ( V ) 

1 

13 

UHF  Radio 

AN/ARC-l6U(V) 

2 

Ik 

Instrument  Landing  System 

AN/ARN-108 

2 

15 

Automatic  Direction  Finder 

DF-206 

1 

l6 

Station  Keeping  Equipment 

AN/APN-169A 

1 

17 

Radar  Beacon  Set 

AN/UPN-25 

1 

18 

TACAN  System 

AN/ARN-118 ( V ) 

1 

19 

UHF/ADF  System 

DF-301E 

1 

20 

Infrared  Detection  & Warning 
and  Flare  Dispenser  System 

1 

21 

ESM/Passive  ECM  Radar 

AN/ALR-56 

1 

22 

Controls  and  Displays 

- 

1 

23 

Airframe  and  Engine  Sensors 

- 

1 
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As  a result  of  the  IDAMST  multiplex  study,  a system 
specification  for  the  IDAMST  Information  Transfer  System 
(ITS)  and  prime  item  development  specifications  for  the 
IDAMST  remote  terminal  and  bus  control  interface  unit  were 
developed  (reference  1,2  and  3).  In  addition,  IDAMST  signal 
list  and  IDAMST  multiplex  system  study  report  and  interface 
specifications  were  generated  (reference  U and  5). 

The  ITS  specification  and  the  subsystem  interface 
specifications  were  derived  from  a detailed  analysis  of  a 
list  of  all  signals  flowing  between  elements  of  the  ITS  and 
the  subsystems.  The  signal  list  was  generated  after  careful 
analysis  of  all  available  technical  data  concerning  each 
avionics  subsystem. 

The  most  significant  result  of  the  study  is  the  design 
of  a near-optimum  multiplex  system,  which  is  the  outgrowth 
of  iterative  analyses  of  detailed  signal  list  data.  The 
multiplex  system  design  employs  a MIL-STD-1 553A  data  bus  to 
link  the  avionics  subsystems  and  computers,  by  way  of  stan- 
dard Remote  Terminals  (RTs)  and  Bus  Control  Interface  Units 
(BCIUs)  which  are  being  developed  for  the  Digital  Avionics 
Information  System  (DAIS)  program  currently  under  way  at 
AFAL. 


Following  the  design  of  the  multiplex  system,  specifi- 
cations were  generated  defining  the  interface  between  each 
subsystem  and  the  IDAMST  Information  Transfer  System  (ITS). 
Here  it  was  learned  that  a significant  number  of  the  avionics 
subsystems  must  be  modified  in  order  to  interface  properly 
with  the  Remote  Terminals  (RTs)  of  the  ITS  (refer  to  tech- 
nical discussion).  It  has  been  assumed  that  the  controls  and 
displays,  and  airframe  subsystems  are  either  to  be  designed 
or  under  development,  and  they  can  therefore  be  designed  to 
interface  directly  with  a pair  of  RTs.  Modification  where 
required  consists  of  replacing  the  control  and/or  indicator 
box(es)  of  the  subsystem  with  a Subsystem  Interface  Unit 
(SSIU),  which  must  be  developed  to  interface  the  subsystem 
with  an  RT. 

A conservative  upper  bound  on  bus  loading  was  calcula- 
ted to  be  13-3%  for  the  recommended  IDAMST  multiplex  system. 

CONCLUSIONS  AND  RECOMMENDATIONS 


The  IDAMST  multiplex  system  study  has  led  to  the  follow- 
ing conclusions  and  recommendations: 
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(a)  A significant  number  of  the  available  "off-the- 
shelf"  subsystems  must  be  modified  in  order  to  integrate 
their  presently  dedicated  control  and  display  functions  into 
the  IDAMST  Controls  and  Display  subsystem. 

(b)  Modification  of  each  available  subsystem  when 
necessary  consists  of  replacing  its  presently  dedicated 
control  and  display  components  with  a special  and  much 
simpler  Subsystem  Interface  Unit  (SSIU/,  which  interfaces 
the  subsystem  with  the  multiplex  system  via  an  RT . 

(c)  The  non-recurring  cost  of  required  SSIU  develop- 
ments is  expected  to  be  partially,  if  not  more  than,  offset 
by  the  savings  which  result  from  the  removal  of  dedicated 
subsystem  control  and  display  components. 

(d)  Avionics  subsystems  which  are  presently  being 
developed  or  are  as  yet  to  be  developed  should  be  designed 
to  interface  directly  with  an  RT,  thus  eliminating  the  need 
for  an  SSIU. 

(e)  It  may  be  more  cost-effective  to  design  each  new 
subsystem  to  interface  directly  with  the  MIL-STD-1553A  data 
bus,  thus  reducing  the  number  and/or  complexity  of  RTs 
required,  as  well  as  obviating  the  need  for  a special  SSIU. 

(f)  It  may  also  be  more  cost-effective  to  design  each 
SSIU  to  interface  existing  subsystems  directly  to  the  MIL- 
STD-1553A  data  bus  without  going  through  an  RT . 

(g)  A trade-off  study  should  be  conducted  to  determine 
whether  it  is  more  cost-effective  to  design  all  SSIUs  and/or 
new  subsystems  to  interface  directly  with  the  MIL-STD-15 53A 
data  bus  than  it  is  to  interface  via  RTs. 

TECHNICAL  DISCUSSION 

The  most  significant  conclusion  arising  from  the 
IDAMST  multiplex  study  is  that  as  few  as  10  and  as  many  as 
19  avionics  subsystems  out  of  a total  of  23  avionics  sub- 
systems in  the  IDAMST  avionics  suite  must  be  modified.  It 
should  be  noted  that  4 avionics  subsystems  (intercommunica- 
tion, IFF,  Controls  and  Displays,  and  Airframe)  do  not 
require  any  modifications,  whereas  10  avionics  subsystems 
(Radar,  Altimeter,  INS,  PA,  HF/SSB  Radio,  VHF/FM  Radio,  UHF 
Radio,  SKE,  Radar  beacon  and  TACAN ) definitely  require  some 
modification,  the  reasons  for  which  are  described  in  Table 
2.  Of  the  remaining  9 avionics  subsystems,  inadequate  data 


TABLE  2.  REASONS  FOR  REQUIRING  A SSIU  FOR  INTEGRATING  SUBSYSTEMS 
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were  available  because  some  of  the  subsystems  are  of  a 
classified  nature,  while  others  are  under  development. 
Subsystem  modifications,  where  required,  are  necessary  as  a 
direct  result  of  the  integrated  cockpit  controls  and  displays 
concept  developed  for  the  IDAMST. 

An  integrated  cockpit  controls  and  displays  concept  for 
the  IDAMST  has  been  developed  in  parallel  with  the  IDAMST 
multiplex  study  and  the  DAIS  program.  This  controls  and 
displays  concept  seeks  to  make  the  pilot  a systems  manager 
rather  than  an  "equation  solver".  It  relies  heavily  on  the 
use  of  the  central  processors.  Bus  Control  Interface  Units 
(BCIUs)  and  RTs  developed  as  an  outgrowth  of  the  DAIS  pro- 
gram . 


Each  of  the  presently  available  subsystems  in  the 
avionics  suite  have  been  designed  to  be  operated  through  its 
own  dedicated  cockpit  (pilot  or  copilot  station)  controls 
and  display  hardware,  rather  than  by  a set  of  integrated 
cockpit  controls  and  displays.  Therefore,  in  the  process  of 
integrating  the  avionics  subsystems  and  the  controls  and 
displays  in  the  IDAMST,  the  minimum  modification  required  of 
any  off-the-shelf  subsystem  is  the  elimination  of  all  dedi- 
cated control  and  display  hardware.  Unfortunately,  other 
modifications  are  also  required  in  many  of  the  presently 
available  subsystems.  These  additional  modifications  amount 
to  the  development  of  Subsystem  Interface  Units  (SSIUs)  to 
replace  the  existing  control  and  display  hardware  that  must 
be  removed  from  all  the  "off-the-shelf"  subsystems.  An  SSIU 
is  required  in  each  of  these  cases  for  one  or  both  of  the 
following  reasons: 

(a)  The  existing  control  and  display  hardware  performs 
some  signal  processing  functions  (such  as  generating  special 
serial  digital  signals  in  the  AN / ARN- 11 8 ( V ) TACAN  System) 
that  cannot  be  performed  by  the  RT  or  the  IDAMST  processor. 

(b)  Some  of  the  subsystem  components  require  signal 
currents  and/or  voltages  (for  example  the  currents  required 
to  drive  an  antenna  coupler  motor  in  the  FM-622A  Radio) 
which  are  in  excess  of  the  output  drive  capability  of  the 
RT ' s Interface  Module  (IM). 

It  is  concluded  that  the  avionics  subsystems  which  are 
presently  being  developed  or  are  as  yet  to  be  developed 
should  interface  directly  with  an  RT . This  will  be  possible 
provided  each  subsystem  developer  receives  the  appropriate 
subsystem  interface  specification  sufficiently  in  advance  in 
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order  to  incorporate  these  requirements  in  his  design. 
Therefore,  it  is  strongly  recommended  that  the  developers  of 
new  avionics  subsystems  be  directed  in  their  respective 
contracts  to  interface  directly  with  a RT  to  allow  the  use 
of  integrated  cockpit  controls  and  displays. 

It  may  be  even  more  desirable  to  require  all  new  avion- 
ics subsystems  to  interface  directly  to  the  MIL-STD-1553A 
data  bus,  rather  than  through  the  intermediary  RT . It  also 
may  be  more  desirable  to  design  each  SSIU  such  that  it 
interfaces  each  existing  subsystem  directly  to  the  data  bus, 
rather  than  through  an  intermediary  RT . Whether  or  not  this 
is  a viable  approach  depends  on  its  cost. 

The  cost  trade-off  associated  with  interfacing  the 
SSIUs  directly  to  the  data  bus  involves  comparing  the  cost 
of  such  an  ITS  with  the  cost  of  the  selected  approach  which 
uses  RTs.  It  may  be  argued  that  since  the  selected  approach 
involving  RTs  requires  the  modification  of  most  available 
subsystems,  that  it  may  not  cost  much  more  to  interface  each 
SSIU  directly  to  the  data  bus.  A valid  counterargument  is 
that  the  former  may  well  cost  less  than  the  latter,  since 
one  RT  is  able  to  serve  several  subsystems.  It  is  therefore 
recommended  that  this  cost  trade  be  performed  in  future 
studies. 

TECHNICAL  APPROACH 

Early  in  the  study  a decision  was  made  to  incorporate 
into  the  IDAMST  the  Remote  Terminals  (RTs)  and  Bus  Control 
Interface  Units  (BCIUs)  developed  for  the  DAIS  hot  bench. 

The  main  reason  for  this  decision  was  that  this  appeared  to 
be  the  only  MIL-STD-1553A  multiplex  system  interface  hard- 
ware which  will  become  available  in  time  for  use  in  the 
IDAMST . 

A signal  list  was  then  generated  for  subsequent  use  in 
the  design  of  the  multiplex  system.  In  the  process  of 
generating  the  various  avionics  subsystems  signal  listings, 
it  was  found  that  all  data  flows  either  from  one  of  the 
three  central  processors  to  a subsystem  or  vice-versa.  In 
no  case  was  terminal-to-terminal  data  transfer  found  to  be 
necessary.  The  reason  for  this  is  that  all  communications 
between  the  subsystems  and  the  cockpit  controls  and  display 
subsystem  require  that  intermediate  processing  of  the  infor- 
mation be  performed  by  one  of  the  three  central  processors. 


In  the  process  of  generating  the  signal  listings  it 
quickly  became  apparent  that  several  typeq  of  interface 
arrangements  are  possible.  Altogether  there  are  four  ways 
of  interfacing  the  subsystems  with  the  data  bus,  as  illus- 
trated in  Figure  1.  Alternative  A is  the  one  that  was  most 
hoped  for  when  the  DAIS  RT  development  program  began,  as  it 
does  not  necessitate  an  intermediary  Subsystem  Interface 
Unit  (SSIU)  between  the  RT  and  the  avionics  subsystem  with 
which  it  communicates.  Unfortunately,  in  the  IDAMST  this 
only  occured  for  four  subsystems  (Intercommunication,  IFF, 
Controls  and  Display,  and  Airframe).  As  few  as  10  .v.nd  as 
many  as  19  subsystems  have  to  be  interfaced  using  an  SSIU  as 
illustrated  in  one  of  the  remaining  alternatives  (B  through 
D)  shown  in  Figure  1. 

Of  those  subsystems  which  require  an  SSIU,  alternative 
D appears  to  be  esthetically  most  pleasing,  though  it  does 
not  make  use  of  the  RTs  developed  under  DAIS,  and  may  be 
less  cost-effective,  for  reasons  discussed  previously  in 
section  3.0.  This  leaves  options  B and  C.  The  only  dif- 
ference between  these  two  options  is  that  signals  which  need 
no  conditioning  are  routed  outside  the  SSIU  in  alternative 
B,  whereas  in  alternative  C they  pass  through  the  SSIU. 
Because  alternative  C is  more  general  (some  subsystems  may 
require  that  all  signals  be  conditioned)  therefore,  it 
(rather  than  B)  has  been  chosen  as  the  most  appropriate 
method  of  interfacing  existing  subsystems  with  the  IDAMST 
multiplex  system. 

SYSTEM  DEFINITION 


The  Information  Transfer  System  (ITS)  is  the  primary 
means  of  communication  among  the  various  avionics  subsystems 
in  the  IDAMST.  It  accommodates  a multitude  of  individual 
baseband  signals,  each  having  a bandwidth  of  less  than  U00 
hertz.  The  ITS  consists  of  a dually  redundant  twisted 
shielded  pair  transmission  medium  ( MIL-STD-1 5 53A  data  bus), 
numerous  Remote  Terminals  (RTs),  three  Bus  Control  Inttrface 
Units  (BCIUs),  and  three  central  processors. 

The  multiplex  data  bus  provides  the  physical  data  link 
between  the  BCIUs  and  the  RTs  within  the  ITS  along  with  the 
means  of  coupling  the  electronic  units  to  the  cable.  It 
functions  asynchronously  in  a command/response  mode,  and 
transmission  occurs  in  a half  duplex  manner.  The  multiplex 
data  bus  employs  the  following  three  modes  of  information 
transfer : 


MIL-STD- 1553A  MULTIPLEX  DATA  BUS 


(a)  BCIU  to  RT  transfer  ( CTT ) 

(b)  RT  to  BCIU  transfer  ( TTC ) 

(c)  RT  to  RT  transfer  (TTT) 

The  RTs  provide  the  electrical  interface  between  the 
bus  and  the  avionics  subsystems.  When  an  RT  recognizes  its 
own  address,  it  responds  to  the  receive/transmit  command  as 
described  in  MIL-STD-1 5 5 3A . The  RT  is  capable  of  sampling, 
converting  and  formatting  AC  and  DC  analog,  discrete,  synchro, 
serial  digital  and  pulse  signals  from  the  subsystem  interfaces 
and  transmitting  the  formatted  values  as  messages  on  the 
data  bus  upon  receipt  of  a command  to  do  so  from  the  BCIU. 

The  RT  is  also  capable  of  receiving  a message  from  the  data 
bus  and  distributing  the  message  to  various  outputs  in 
appropriate  forms  such  as  AC  or  DC  analog,  discrete,  synchro, 
serial  digital  and  torquing  pulses. 

The  BCIU  unit  provides  the  interface,  control  and  data 
transfer  function  required  to  connect  a processor  with  two 
independent  multiplexed  data  buses.  Each  BCIU  interfaces 
two  independent  data  buses  to  one  processor.  The  BCIU  is 
directed  to  operate  in  either  a remote  mode  or  a master  mode 
by  its  interfacing  processor.  At  any  one  time  there  will  be 
only  one  BCIU  in  the  Master  Mode  in  any  one  data  bus  system. 

In  other  words  one  of  the  three  central  processing  units  in 
the  IDAMST  serves  as  a controller  of  traffic  on  the  bus. 

Each  BCIU,  when  working  in  conjunction  with  its  associated 
processor,  has  the  capability  of  operating  in  one  of  the 
following  modes: 

(a)  perform  as  a remote  unin  capable  of  responding  to 
commands  received  from  another  BCIU  via  the  data  bus. 

(b)  perform  as  an  active  BCIU  for  the  processor  desig- 
nated as  the  bus  control  processor. 

(c)  perform  as  a bus  monitor  to  verify  proper  operation 
of  the  multiple  system. 

SYSTEM  DIAGRAM 


Figure  2 illustrates  the  baseline  IDAMST  Information 
Transfer  System  (ITS)  which  has  been  designed  to  accommodate 
the  baseline  IDAMST  avionics  suite  listed  in  the  Table  1. 

The  IDAMST  ITS  in  Figure  2 contains  three  central  processors 


called  IDAMST  processors,  and  three  Bus  Control  Interface 
Units  (BCIUs)  which  interface  the  IDAMST  processors  with  the 
multiplex  data  bus.  In  the  IDAMST  ITS  eight  Remote  Terminals 
(RTs)  are  required:  Two  for  the  controls  and  displays  and 

the  remainder  for  the  avionics  subsystems.  Remote  Terminal 
1 is  assigned  to  all  control  units.  Remote  Terminal  2 
interfaces  with  all  the  display  hardware.  Remote  Terminals 
3, U, 5,6,7  and  8 interface  with  the  various  subsystems  as 
shown  in  the  Figure  2.  Remote  Terminal  9 is  tentatively 
shown  to  interface  with  the  Flight  Control  Systems,  as  the 
exact  requirements  are  not  known  at  this  time.  Remote 
Terminal  10  is  shown  interfacing  with  the  Global  Positioning 
System  (GPS)  and  the  Joint  Tactical  Information  Distribution 
System  (JTIDS).  This  RT  is  not  recommended  for  inclusion  in 
the  baseline  IDAMST  System  at  present,  but  is  shown  to 
illustrate  expandability  for  future  growth. 

The  IDA.MST  Controls  and  Display  configuration  developed 
by  AFAL  is  illustrated  in  Figure  3,  which  has  been  integrated 
in  the  pilot  and  copilot  positions  of  the  cockpit.  Table  3 
consists  of  a controls  and  displays  equipment  list.  All  the 
controls  and  display  equipment  will  be  newly  developed 
specifically  for  the  IDAMST,  but  will  draw  heavily  on  the 
results  of  the  DAIS  controls  and  display  system  now  under 
development.  Since  all  controls  and  display  equipment  will 
be  newly  developed  to  interface  directly  with  the  RTs  of  the 
IDAMST  multiplex  system,  therefore  no  SSIUs  are  required  for 
the  controls  and  display  subsystem. 

BCIU  AND  PROCESSOR  INTERFACE 


The  processor  and  the  BCIU  interface  through  a Program 
Control  Input/Output  (PIO)  channel,  a Direct  Memory  Access 
(DMA)  channel,  and  a set  of  interrupts  as  described  in 
reference  3. 

AVIONICS  SUBSYSTEMS  INTERFACES 


Each  avionics  subsystem  will  interface  with  the  IDAMST 
multiplex  system  via  one  or  more  RTs.  Each  RT  will  be  capa- 
ble of  interfacing  with  a variety  of  avionics  subsystem  sig- 
nal types  by  means  of  interface  modules  (iMs)  contained  in 
the  RT.  Two  types  of  interface  modules  are  required;  Input 
interface  modules  and  output  interface  modules.  Character- 
istics of  input  and  output  interface  modules  are  described 
in  reference  2. 
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TABLE  3 CONTROLS  AND  DISPLAY  EQUIPMENT  LIST 


LRU  Key 


Nomenclature 


7-1-1 

7-1-2 

7-1-3 

7-1-1* 

7-1-7 

7-1-5 

7-1-5 


7-1-5 

7-1-5 

7-1-5 

7-1-5 

7-1-5 


Modular  Programmable  Display  Generator  H 1 
( MPDG  l) 

Modular  Programmable  Display  Generator  #2 
(MPDG  2) 

Modular  Digital  Scan  Converter  (MDSC) 

Display  Switch/Memory  Unit  (DS/MU) 
Alpha/Numeric  Symbol  Generator  (A/N  SG) 
Head-Up  Display  H 1 (Pilot's),  (HUD  l) 

Head-Up  Display  §2  (Copilot's),  (HUD  2) 
Horizontal  Situation  Display  #1  (Pilot's), 

( HSD  1) 

Horizontal  Situation  Display  §2  (Copilot's), 
(HSD  2) 

Multipurpose  Display  Hi  (Pilot's),  ( MPD  l) 
Multipurpose  Display  #2  (Copilot's),  (MPD  2) 
Multipurpose  Display  #3  (Common),  (MPD  3) 
Integrated  Multifunction  Keyboard  Hi  Display, 
( IMK  1 Display) 

Integrated  Multifunction  Keyboard  §2  Display, 
(IMK  2 Display) 

Master  Mode  Keyboard  (MMK) 

Integrated  Multifunction  Keyboard  #1 
(Pilot's)  , (IMK  1) 

Integrated  Multifunction  Keyboard  H2  (Co- 
pilot's), (IMK  2) 

Data  Entry  Keyboard  Hi  (Pilot's),  ( DEK  l) 

Data  Entry  Keyboard  H 2 (Copilot's),  (DEK  2) 
Column  Control  Assembly  (CCA) 

Multipurpose  Display  Control  1 (Pilot's), 

( MPDC  1) 

Multipurpose  Display  Control  2 (Copilot's), 
(MPDC  2) 

Multipurpose  Display  Control  3 (Common), 

(MPDC  3) 

Start-Up  Panel  (SUP) 

Avionics  Control  Panel  1 (Pilot's),  (ACP  l) 
Avionics  Control  Panel  2 (Copilot's),  (ACP  2) 
Hand  Controller  Unit  (HCU) 

Sensor  Control  Panel  (SCP) 
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REMOTE  TERMINAL  INTERFACE 


Each  remote  terminal  will  contain  several  interface 
modules  to  interface  with  various  subsystems.  Line  Replace- 
able Units  of  each  subsystem  are  also  dedicated  to  one  or 
more  remote  terminal(s).  In  the  following  paragraphs,  the 
number  and  locations  of  remote  terminals  as  well  as  the  com- 
plement of  interface  modules  in  each  is  specified.  This  in- 
formation has  been  derived  from  a set  of  detailed  IDAMST 
signal  listings  derived  from  the  baseline  avionics  suite  de- 
scribed in  Table  1.  Part  of  the  following  information  was 
generated  from  vendor  supplied  data  concerning  the  YC-lU 
AMST  configuration.  Sufficient  data  concerning  the  YC-15 
configuration  was  not  available  at  the  time  of  the  study. 

LRU-RT  ASSIGNMENT 


One  or  more  RTs  are  required  to  interface  the  Line  Re- 
placeable Units  (LRUs)  of  each  avionics  subsystem  as  well  as 
each  control  and  display  unit  which  participates  in  data 
transfer  with  the  multiplex  data  bus.  Figure  2 illustrates 
all  the  subsystems  including  controls  and  displays  together 
with  their  RT  assignemnts. 

REMOTE  TERMINALS  CONFIGURATION 


Table  4 describes  in  detail  the  Interface  Modules  ( IMs ) 
required  in  each  of  the  eight  remote  terminals.  This  in- 
formation has  been  derived  from  a detailed  analysis  of  the 
IDAMST  signal  listings.  Table  5 also  contains  the  number  of 
Interface  Modules  ( IMs ) in  each  RT.  Note  that  each  RT 
requires  more  than  8 IMs,  therefore,  "long"  RTs  capable  of 
accommodating  l6  IMs  are  needed  at  all  locations. 

LOCATIONS  OF  REMOTE  TERMINALS 

Table  6 contains  a list  of  remote  terminal  locations. 
Note  that  Table  6 does  not  specify  the  locations  of  RT-9  and 
RT-10  shown  in  Figure  2.  RT-9  is  used  for  Flight  Control 
Systems  Interface  and  this  information  is  not  available  at 
present,  but  this  RT  will  be  placed  near  the  Flight  Control 
System  sensors  and/or  computer.  RT-10  is  not  proposed  at 
present  but  represents  future  growth. 

BUS  LOADING 

An  upper  bound  on  bus  loading  was  calculated  to  be 
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TABLE  k PROPOSED  REMOTE  TERMINALS  CONFIGURATION 


Interface  Module 

Input / 

Signal 

Update  Rate 

RT  # 

§ of  IMs 

Output 

Type 

Per  Sec. 

1 

1 

Input 

Serial  Digital 

8 1 

1 

2 

Input 

Single  Ended 

8 

Discrete 

1 

1 

Output 

Diff.  AC  Analog 

32 

1 

It 

Output 

Diff.  DC  Analog 

8 

1 

3 

Output 

Single  Ended 

Discrete 

8 

2 

1 

Input 

Serial  Digital 

6k 

2 

1 

Input 

Serial  Digital 

32 

2 

6 

Input 

Single  Ended 

Discrete 

8 

2 

1 

Output 

Single  Ended 

1 

8 

Discrete 

3 

1 

Input 

Diff.  DC  Analog 

3 

3 

1 

Input 

Single  Ended 

Discrete 

8 

3 

1 

Input 

Single  Ended 

Discrete 

1 

3 

It 

Output 

Synchro 

8 

3 

2 

Output 

Switch  closure 

(open/ 28VDC ) 

8 

3 

1 

Output 

Single  Ended 

Discrete 

8 

3 

1 

Output 

Single  Ended 

Discrete 

1 

1* 

1 

Input 

Diff.  AC  Analog 

8 

It 

1 

Input 

Switch  closure 

( open/ GND ) 

2 

It 

2 

Output 

Two  wire  synchro 

8 

It 

1 

Output 

Synchro 

32 

8 

It 

5 

Output 

Diff.  AC  Analog 

It 

1 

Output 

Diff.  DC  Analog 

8 

L 

1 

Outout 

Diff.  DC  Analog 

16 

32  |] 

8 

5 

1 

Input 

Serial  Digital 

5 

I 

Input 

Serial  Digital 

5 

1 

Input 

Diff.  DC  Analog 

8 

5 

1 

Input 

Switch  closure 

( open/28VDC ) 

8 

5 

3 

Input 

Single  Ended 

Discrete  8 
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TABLE  1*  PROPOSED  REMOTE  TERMINALS  CONFIGURATION  (CONT'D) 


Interface 

RI!ltRRI 

Input/ 

Signal 

Update  Rate 

RT  § 

tt  of  IMS 

Output 

Type 

Per  Sec. 

5 

1 

Input 

Single  Ended 

Discrete 

2 

5 1 

Output 

Serial  Digital 

32 

5 3 

Output 

Synchro 

32 

5 1 

Output 

Switch  closure 

(open/28VDC) 

l6 

5 1 

Output 

Switch  closure 

(open/ 28VDC ) 

8 

5 1 

Output 

Single  Ended 

Discrete 

2 

6 1 

Input 

Serial  Digital 

8 

6 2 

Input 

Diff.  DC  Analog 

8 

6 3 

I nput 

Single  Ended 

Discrete 

8 

6 1 

Output 

Two  Wire  synchro 

8 

6 1 

Output 

Serial  Digital 

l6 

6 1 

Ou  Lput 

Serial  Digital 

8 

6 1 

Output 

Diff.  DC  Analog 

16 

6 2 

Output 

Diff.  DC  Analog 

8 

6 1 

Output 

Switch  closure 

(open/28VDC) 

8 

6 1 

Output 

Single  Ended 

Discrete 

8 

7 1 

Input 

Serial  Digital 

8 

7 3 

Input 

Diff.  DC  Analog 

8 

7 3 

Input 

Single  Ended 

Discrete 

8 

7 1 

Output 

Serial  Digital 

l6 

7 1 

Output 

Synchro 

32 

7 1 

Output 

Diff.  DC  Analog 

l6 

7 2 

Output 

Diff.  DC  Analog 

8 

7 1 

Output 

Switch  closure 

( open/ 28VDC ) 

8 

7 1 

Output 

Single  Ended 

Discrete 

8 

8 1 

Input 

Serial  Digital 

8 

8 3 

Input 

Diff.  DC  Analog 

8 

8 3 

Input 

Single  Ended 

Discrete 

8 

8 

1 

Output 

Diff.  DC  Analog 

8 

8 

1 

Output 

Single  Ended 

Discrete 

8 

8 


TABLE  5 NUMBER  OF  IMs  IN  EACH  RT 


RT 

ft 

§ of  IMs 

1 

11 

2 

9 

3 

11 

4 

15 

5 

15 

6 

ll* 

7 

14 

8 

9 

TABLE  6 

PROPOSED  LOCATIONS  OF 

THE  REMOTE  TERMINALS 

RT  ft 

LOCATION 

1 

FDP-L 

Flight 

Deck  Panel  - Left 

2 

FDP-R 

Flight 

Deck  Panel  - Right 

3 

FDA-L 

Flight 

Deck  Avionics  - Left 

k 

FDA-L 

Flight 

Deck  Avionics  - Left 

5 

FDA-R 

Flight 

Deck  Avionics  - Right 

6 

CAB-L 

Cargo 

Avionics  Bay  - Left 

7 

CAB-R 

Cargo 

Avionics  Bay  - Right 

8 

NWN 

Nose  Wheel  Well 
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13.3%  for  the  recommended  IDAMST  multiplex  system.  It  was 
calculated  from  the  data  provided  in  Table  k.  In  calculating 
bus  loading  it  was  assumed  that  all  available  channels  of 
each  IM  were  utilized  at  the  required  update  rates  derived 
from  the  signal  list.  In  actual  fact,  many  channels  in  the 
IMs  are  not  used,  therefore  the  73. 3 1 bus  loading  figure 
represents  a conservative  upper  bound.  Note  that  there  are 
l6  IMs  in  each  DAIS/  IDAMST  long  RT . 
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ABSTRACT 

Fiber  optic  transmission  is  emerging  as 
an  attractive  alternative  to  coaxial 
cable  for  wideband  multi-user  data  dis- 
tribution networks.  This  paper  discusses 
the  alternatives  encountered  in  the  de- 
sign and  Implementation  of  a fiber  optic 
data  bus  system.  The  topics  discussed 
include  network  topology,  data  flow 
control  procedures,  multiplexing  techni- 
ques, and  optical  network  elements. 


INTRODUCTION 

Recent  advances  in  communications  tech- 
nology and  devices,  as  well  as  a general 
trend  toward  an  increasing  quantity  of 
communications  traffic,  have  generated 
a need  by  which  a number  of  physically 
separated  users  may  efficiently  gain 
access  to  a variety  of  information 
services.  Since  a substantial  portion 
of  the  information  exchange  needs  of 
a modern  facility  involves  wideband 
Information  such  as  high  speed  digital 
data,  graphics  displays,  facsimile, 
and  television,  suitable  transmission 
media  must  be  capable  of  supporting 
and  distributing  this  wideband  traffic 
efficiently  among  a number  of  users. 

In  addition,  there  is  frequently  a 
need  to  provide  service  to  a large 
number  of  low  and  medium  speed  digital 
data  terminals  and  voice  grade  analog 
users  (telephones)  on  the  same  networks. 

Conventional  wideband  data  bus  networks 
have  been  Implemented  with  coaxial 
cable  as  the  transmission  medium.  Co- 
axial cable  networks  have  been  con- 
structed and  their  reliability  and  cost 
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effectiveness  have  been  demonstrated; 
however,  they  do  have  certain  drawbacks. 
Recent  advances  in  optical  fiber  trans- 
mission technology  allows  consideration 
of  wideband  data  bus  networks  which 
overcome  some  of  the  limitations  of 
coaxial  cable,  primarily  with  regard 
to  size,  bandwidth,  security  and  sus- 
ceptibility to  electromagnetic  inter- 
ference. Properties  of  optical  fibers 
such  as  small  size  and  bandwidth  indepen- 
dent attenuation  permit  the  design  of 
wideband  multi-user  networks  which  are 
flexible  and  offer  considerable  potential 
expansion . 

Comparing  the  downward  trend  in  the  cost 
of  optical  fiber  and  components  with  the 
rising  cost  of  coaxial  cable  shows  a 
clear  cut  economic  advantage  emerging 
for  fiber  optic  systems  in  wideband  data 
bus  networks. 

NETWORK  TOPOLOGY 

A topological  description  of  a communi- 
cations network  serves  to  determine  the 
physical  and  logical  relationships  among 
the  various  nodes  and  links  which  make 
up  the  network.  The  topology  of  the 
network  in  conjunction  with  the  multiple 
access  techniques  determines  the  follow- 
ing network  parameters  and  characteris- 
tics: set  up  time  to  establish  a link; 

response  time,  grade  of  service,  infor- 
mation handling  requirements,  expand- 
ability and  flexibility.  Link  set  up 
time  is  defined  as  the  time  required  to 
provide  service  to  a terminal  after  a 
request  for  service  has  been  made.  Res- 
ponse time  refers  to  delay  encountered 
between  sending  a message  and  receiving 
a reply  or  acknowledgement  of  the  message 
and  usually  does  not  include  propagation 
time.  The  grade  of  service  provided  by 
the  network  includes  such  factors  as 
signal  quality  ( s i gna 1 - t o-no i s e ratio 
or  bit  error  rate)  and  probability  of 
blocked  calls. 

Network  topology  may  be  divided  into 
access  (local)  topology  and  center 
topology  as  shown  in  Figure  1.  Access 
topology  consists  of  that  portion  of 
the  network  to  which  subscriber  elements 
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Data  flow  controls  may  be  divided  into 
four  categories:  communication  proto- 

cols, flow  control  strategies,  routing 
strategies,  and  on-line  monitoring  and 
control.^  A communication  protocol  is 
set  of  rules  established  to  manage  the 
information  exchange  between  a pair  of 
terminals.  Protocol  allows  the  terminals 
to  understand  and  cooperate  with  one 
another  so  that  the  information  exchange 
may  be  made  in  an  orderly  fashion.  A 
flow  control  strategy  is  a set  of  rules 
that  governs  the  acceptance  of  data 
onto  the  network  in  order  to  optimize 
the  trade-off  between  congestion  during 
busy  periods  and  system  performance 
during  normal  operating  conditions. 
Routing  strf tegies  are  needed  to  deter- 
mine when  and  where  a message  should  be 
transmitted  after  it  has  been  accepted 
onto  the  network  according  to  the  flow 
control  procedures.  The  design  objective 
of  the  routing  strategy  is  to  minimize 
the  message  delay  ar.d  optimize  the 
throughput  according  to  traffic  condi- 
tions. On-line  monitoring  and  control 
are  necessary  to  monitor  system  malfunc- 
tions and  performance  and  to  provide 
diagnostic  information. 


constructed  and  their  reliability  and 
cost  effectiveness  have  been  demonstrated. 
Recent  advances  in  optical  fiber  trans- 
mission technology  allow  consideration 
of  distribution  networks  which  overcome 
some  of  the  limitations  of  coaxial  cable 
distribution,  primarily  with  regard  to 
physical  size  and  bandwidth  capacity. 
Certain  properties  of  optical  fibers  such 
as  bandwidth  independent  attenuation  and 
small  size  permit  the  design  of  wideband 
multi-user  distribution  systems  using 
temporally  modulated  carriers  which 
are  very  flexible  and  offer  tremendous 
potential  for  future  expansion.  Present 
fiber  technology  is  sufficiently  advanced 
to  permit  replacement  of  many  coaxial 
cable  distribution  networks  with  an 
equivalent  optical  fiber  system. 

Frequency  Division  Multiple  Access  (FDMA) 

A very  common  modulation  technique  utili- 
zing temporally  modulated  carrier  wave- 
forms is  frequency  division  multiple 
access.  Multiple  access  to  a wideband 
communications  network  using  frequency 
division  techniques  has  been  considered 
an  attractive  possibility  for  some  time 
and  has  been  the  object  of  considerable 
study. 


MULTIPLEXING  TECHNIQUES 

The  method  by  which  several  message 
signals  are  multiplexed  onto  a single 
transmission  channel  is  one  of  the  key 
considerations  in  the  design  of  a wide- 
band multi-user  data  bus  system.  The 
various  access  channels  are  characterized 
by  a distinct  type  of  modulation  im- 
pressed upon  a carrier  waveform.  Elec- 
tromagnetic fields  are  characterized  by 
variations  in  time  and  space,  hence 
there  are  two  fundamental  properties  of 
the  carrier  waveforms  which  may  be  modu- 
lated. IiK  conventional  wideband  multi- 
user networks  operating  at  radio  fre- 
quencies, multiple  access  channels  are 
characterized  by  modulating  the  carrier 
waveforms  in  the  temporal  domain;  for 
example,  time  division  multiplexing  (TDM) 
and  frequency  division  multiplexing  (FDM). 
Optical  frequency  carrier  waveforms,  when 
used  with  optical  fiber  transmission 
channels,  possess  special  qualities  - 
short  optical  wavelength,  negligible 
adjacent  fiber  crosstalk,  and  small 
fiber  size  - which  permit  the  concep- 
tualization of  a class  of  multiple  access 
techniques  based  on  modulation  of  the 
carrier  in  time  and  space  simultaneously. 
The  use  of  such  a multiplexing  technique 
could  have  profound  implications  in  the 
design  of  wideband  multi-user  data  bus 
systems. 

Wideband  multi-user  distribution  systems 
Implemented  with  coaxial  cable  have  been 


Most  of  the  problems  encountered  in  the 
implementation  of  an  FDMA  system  are  re- 
lated to  the  fact  that  all  signals  on 
the  transmission  channel  are  present 
at  each  receiver  simultaneously.  When 
several  signals  pass  through  receiver 
and  transmitter  electronics,  they  inter- 
act within  the  transmitters  and  receivers 
and  suffer  transmission  impairments.  The 
major  source  of  these  impairments  is  the 
nonlinear  transfer  characteristics  of 
sources,  detectors  and  amplifiers  which 
cause  intermodulation  interference. 

In  an  optical  fiber  system,  two  possi- 
bilities for  frequency  division  exist. 

In  the  first  system,  illustrated  in 
Figure  3,  the  various  access  channels 
are  characterized  by  several  radio  fre- 
quency subcarriers  impressed  upon  a 
single  optical  frequency  carrier.  This 
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Figure  3 - Frequency  Division  Multiple 
Access  with  Radio  Frequency  Subcarriers 
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are  directly  connected.  Typically, 
users  are  grouped  according  to  their 
physical  location,  type  of  service, 
data  rate,  or  some  other  common  char- 
acteristic. Elements  found  in  the 
access  topology  may  include  local  ex- 
changes, PBXs,  or  other  subscriber 
facilities.  Center  topology  refers  to 
that  portion  of  the  network  through 
which  several  access  topologies  are 
interconnected.  Typical  elements  in- 
cluded in  the  center  topology  are  trunk 
switching  centers,  concentrators,  multi- 
plexers, trunk  transmission  facilities, 
and  other  shared  services. 

Access  topology  refers  to  the  manner  in 
which  local  users  are  grouped  and  inter- 
act and  represents  the  lowest  level  in 
the  network  hierarchy.  Two  possible 
architectures  for  the  access  topology 
are  the  loop  network  and  the  star  net- 
work. Loop  networks  pass  all  informa- 
tion through  each  node  and  require  drop 
and  insert  elements  in  order  to  access 
the  subscriber  terminals.  Star  networks 
require  a centralized  selection  process 
which  is  implemented  by  a branching 
element.  Star  networks  are  presently 
more  attractive  than  loop  networks 
partially  due  to  the  difficulty  of 
fabricating  low  loss  optical  drop  and 
Insert  elements.  In  addition,  losses 
encountered  in  a loop  system  Increase 
linearly  with  the  number  of  terminals 
while  the  losses  increase  logarithmi- 
cally with  the  number  of  terminals  in 
a star  system.  This  problem  can  be 
alleviated  somewhat  by  constructing 
drop  elements  which  tap  variable  amounts 
of  optical  power  from  the  main  bus,  but 


at  the  expense  of  fabrication  cost  and 
interchangeability  of  drop  elements. 

An  intermediate  position  between  loop 
and  star  networks  is  the  K-connected 
network  shown  in  Figure  2 in  which  the 
maximum  number  of  nodes  that  a signal 
must  traverse  before  it  reaches  its 
destination  is  equal  to  K.  K-connected 
networks  have  the  advantage  of  alternate 
routing  in  the  case  of  failure  of  a 
particular  link  or  node. 

If  it  is  necessary  to  interconnect  two 
or  more  local  user  groups,  a center 
topology  must  be  developed.  Such  situ- 
ations generally  arise  when  two  or  more 
concentrated  user  populations  are  physi- 
cally separated,  if  the  user  service 
demands  exceed  the  capacity  of  a single 
access  network  or  if  different  categories 
of  users  must  interact.  Typically,  a 
local  network  will  interface  the  center 
network  via  a buffer  which  permits  the 
translation  of  signals  from  the  access 
network  into  a form  which  can  be  handled 
by  the  center  network  and  vice  versa. 
Center  networks  may  be  interconnected 
using  a variety  of  techniques,  and  often 
a combination  of  loop  and  star  topologies 
is  employed. 

DATA  FLOW  CONTROL 

The  manner  by  which  data  traffic  is 
controlled  and  routed  substantially 
impacts  network  performance  characteris- 
tics such  as  link  set  up  time,  reply  de- 
lay, probability  of  blocked  service,  and 
channel  utilization  efficiency.  In  any 
communications  system,  it  is  essential 
to  have  a set  of  well  designed  control 
procedures  to  insure  efficient  and  smooth 
transfer  of  information  in  the  system 
Control  procedures  are  needed  to  facili- 
tate efficient  use  of  network  resources, 
to  detect  and  correct  errors  and  system 
element  failures,  and  to  prevent  traffic 
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system  is  identical  to  most  conventional 
(i.e.,  coaxial  cable  systems,  microwave 
satellite  systems)  multiple  access  commu- 
nications systems  except  that  a centra 
carrier  is  present  at  an  optical 
frequency.  In  such  a system,  optical 
power  coordination  is  required  to  pre- 
vent the  large  signals  from  masking 
weaker  ones. 

An  alternative  FDMA  technique  is  illus- 
trated in  Figure  4.  In  this  system,  the 
multiple  access  channels  are  distin- 
guished by  several  optical  frequency 
carriers.  This  type  of  frequency  divi- 
sion is  often  called  color  multiplexing 
since  the  various  carriers  are  emitted 
by  light  sources  operating  at  different 
wavelengths  or  colors.  For  example, 
message  modulation  intended  for  one 
channel  is  applied  to  the  light  source 
corresponding  to  that  channel.  At  the 
receivers,  the  incoming  optical  signal 
is  optically  filtered  prior  to  hitting 
the  detectors,  chus  eliminating  the  pro- 
blems encountered  when  signals  from 
several  channels  pass  through  the  re- 
ceiver simultaneously. 

Time  Division  Multiple  Access  (TDMA) 

Temporally  modulated  carrier  waveforms 
in  an  optical  fiber  system  are  also 
possible  in  the  form  of  a time  division 
multiple  access  format.  Time  division 
multiplexing  techniques,  like  FDMA,  have 
be  »n  studied  extensively  and  many  TDMA 
systems  have  been  implemented  with  co- 
axial cable.  TDMA  techniques  are 
particularly  attractive  for  optical 
fiber  systems  since  the  performance  and 
lifetime  of  optical  fiber  light  sources 
is  improved  when  operated  in  a pulsed 
rather  than  continuous  mode. 

In  a TDMA  system,  a terminal  requesting 
access  to  the  network  is  assigned  exclu- 
sive use  of  a transmission  channel 
during  specified  time  slots.  Thus, 
transmissions  from  different  terminals 
do  not  overlap,  and  the  problems  asso- 
ciated with  several  different  signals 
being  incident  on  a detector  simultane- 
ously are  avoided.  The  price  that  is 
paid  for  eliminating  the  effects  of 
signal  interaction  is  that  network 
timing  is  generally  required. 
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The  simplest  example  of  channel  alloca- 
tion in  a TDMA  system  is  shown  in  Figure 
5.  The  time  axis  Is  divided  into  frames 
Tj  seconds  in  length,  and  each  frame  is 
subdivided  into  N slots  of  duration  tg 
seconds.  In  this  example,  each  of  the  N 
access  channels  consists  of  a single  time 
slot  within  each  frame;  thus,  the  ic^ 
access  channel  consists  of  the  ic^  time 
slot  in  each  frame.  Many  TDMA  fiber  op- 
tic systems  have  already  been  built  using 
presently  available  components. 

Spread  Spectrum  Multiple  Access  (SSMA) 

In  TDMA  and  FDMA,  the  time  axis  or  the 
frequency  spectrum  is  divided  into  a 
number  of  separate,  distinct  regions 
with  each  region  corresponding  to  a parti- 
cular access  channel.  Spread  spectrum 
multiple  access  is  a multiplexing  techni- 
que in  which  the  carrier  waveforms  dis- 
tinguishing the  access  channels  overlap 
in  both  time  and  frequency.  Since  the 
signals  from  several  channels  are  present 
on  a transmission  line  simultaneously 
and  also  overlap  in  frequency,  some 
means  must  be  provided  for  separating 
the  signals  at  a receiver.  This  is 
accomplished  by  using  wideband  multiple 
access  carrier  waveforms  which  are  ortho- 
gonal^  and  may  be  separated  at  a receiver 
using  correlation  techniques.-*  ^ The 
carrier  waveforms  must  be  orthogonal, 
but  otherwise  arbitrary  patterns  in  time 
or  frequency  may  be  used.  In  practice, 
a systematic  coding  procedure  greatly 
simplifies  the  modulation  and  demtdula- 
tion  equipment.  Each  wideband  carrier 
is  assigned  permanently  to  a particular 
receiver;  thus,  the  carriers  also  serve 
as  destination  addresses.  Each  receiver 
has  a copy  of  its  particular  carrier 
waveform  stored  locally  and,  upon  re- 
ceiving a signal  from  the  transmission 
line,  correlates  the  received  signal 
with  the  locally  stored  waveform  to 
extract  the  message  information.  The 
carrier  bandwidth  is  typically  2 to  4 
orders  of  magnitude  larger  than  the 
message  bandwidth;  hence,  "spread  spec- 
trum." The  message  is  inserted  onto 
the  carrier  as  a slowly  varying  modula- 
tion, which  may  be  either  analog  or 
digital.  Since  the  carrier  waveforms 
are  chosen  to  be  orthogonal,  any  re- 
ceiver responds  only  to  its  own  carrier, 
and  all  other  carriers  appear  as  noise 
at  the  output  of  the  correlator. 
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Figure  4 - Frequency  Division  Multiple 
Access  With  Several  Optical  Frequency 
Carriers 
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Figure  5 - Time  Division  Multiple  Access 
System 
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Perhaps  the  most  easily  understood 
example  of  an  SSMA  system  Is  one  in 
which  the  carrier  waveforms  are  a series 
of  pulses  as  shown  in  Figure  6.  The 
time  axis  is  divided  into  time  slots 
of  length  T - 1/fj,  where  f^  is  the  bit 
rate  of  the  message  source.  The  message 
is  assumed  to  consist  of  a stream  of 
ones  and  zeros.  One  bit  (one  or  zero) 

In  the  message  is  transmitted  in  T 
seconds.  The  slots  of  length  T are 
divided  into  much  smaller  slots  of 
length  AT,  where  1/AT  8 W is  the  total 
available  system  bandwidth.  These 
smaller  slots  of  length  AT  are  usually 
referred  to  as  chips.  The  number  of 
chips  needed  to  specify  each  message 
bit  is  T/AT  and  is  typically  10^  to 
10^.  Only  11  chips  per  bit  are  shown 
in  Figure  6 for  simplicity.  These 
chip  sequen~.es  constitute  the  various 
carrier  waveforms  and  are  often  shift 
register  codes  which  are  easily  de- 
signed to  be  orthogonal  sequences. 

For  example,  the  first  access  channel 
in  Figure  6 is  distinguished  by  the 
Chip  sequence  1,  0,  0,  1,  1,  0,  1,  0, 

1,  0,  1.  To  convey  message  informa- 
tion, the  chip  sequence  must  be  modi- 
fied. For  example,  if  binary  infor- 
mation is  to  be  transmitted  the  chip 
sequence  may  be  complemented  to  denote 


Pulse  Address  Multiple  Access  (PAMA)^ 

Pulse  address  multiple  access  systems 
are  designed  to  combine  some  of  the 
best  characteristics  of  FDMA,  TDMA 
and  SSMA  while  avoiding  many  of  their 
problems.  PAMA  systems  may  incorporate 
some  attractive  features  of  TDMA  such 
as  time  gating  for  signal  separation 
and  the  ability  to  operate  without 
power  coordination.  A key  feature  of 
FDMA  is  operation  without  network 
timing.  PAMA  systems  are  generally 


characterized  by  distinct  carrier  wave- 
forms permanently  assigned  to  receivers 
which  also  serve  as  destination  addresses 
as  in  SSMA  systems,  but  avoid  the  strict 
synchronization  problems  encountered  in 
SSMA.  PAMA  systems  are  also  attractive 
because  the  time  required  to  lock  a re- 
ceiver to  an  incoming  signal  is  short  and 
a minimum  of  equipment  is  needed. 

An  access  channel  in  a PAMA  system  con- 
sists of  a series  of  pulses  in  specified 
time  slots  and  frequency  bands.  The 
pulses  and  the  intervals  between  them 
constitute  a distinct  pattern  which 
carries  the  multiple  access  information. 

A wide  variety  of  techniques  for  adding 
digital  or  analog  message  modulation  to 
the  carrier  are  possible.  An  example 
of  a PAMA  system  is  illustrated  in 
Figure  7.  Each  multiple  access  waveform 
(series  of  pulses)  can  be  specified  by 
dividing  the  t ime- f r equency  plane  into 
a matrix.  The  time  axis  is  divided  into 
frames  of  length  T,  each  of  which  is 
subdivided  into  slots  of  length  ts.  The 
available  frequency  spectrum  is  divided 
into  numbered  bands  of  bandwidth  B.  In 
general,  an  access  channel  or  carrier 
waveform  is  specified  by  a sequence  of 
numbers  xx,  xi.*  , where  x^  * 0 pre- 
scribes no  pulse  in  time  slot  i and  x^  * 
j prescribes  a pulse  in  frequency  band 
J in  time  slot  i.  Thus,  channel  1 in 
Figure  7 is  specified  by  1,  0,  0,  3,  0, 

1,  4,  0;  channel  2 is  specified  by  3,  1, 
0,  0,  0,  3,  2,  0 and  channel  3 by  0,  0, 

2,  4,  0,  5,  1,  0. 
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Figure  6 - Three  Channel  Spread  Spectrum 
Multiple  Access  System 


Figure  7 - Three  Channel  Pulse  Access 
Multiple  Access  System 


Message  modulation  may  be  encoded  in 
a variety  of  forms.  On  channel  1 a 
form  of  frequency  shift  keying  (FSK)  can 
be  used  where  the  basic  pulse  sequence 
Indicates  a one,  and  a zero  is  conveyed 
by  shifting  all  pulses  into  the  next 
higher  frequency  band.  Note  that  the 
entire  pulse  sequence  is  transmitted 
for  each  message  bit.  Digital  pulse 
position  modulation  (DPPM)  is  used  on 
channel  2:  the  basic  sequence  3,  1, 

0,  0,  0,  3,  2,  0 conveys  a one  while 
the  sequence  0,  3,  1,  0,  0,  0,  3,  2 
conveys  a zero.  Analog  signals  may 
be  transmitted  using  the  modulation 
format  shown  for  channel  3.  Here, 
very  narr o w pulses  are  transmitted  in 
the  time  slots  determined  by  the  channel 
designation  0,  0,  2,  4,  0,  3,  1,  0. 

These  pulses  are  much  narrower  than  the 
time  slot  width  t and  their  position 
within  the  time  slot  corresponds  to  the 
amplitude  of  a sampled  analog  waveform, 
hence  it  is  referred  to  as  analog  PPM. 

Although  PAMA  systems  can  operate  with- 
out network  timing,  their  performance 
is  improved  and  their  capabilities  are 
expanded  by  incorporating  timing.  Con- 
sider the  pulse  sequence  of  channel  1 
in  Figure  7.  Without  network  timing, 
the  pulse  sequence  (carrier  waveform) 

1,  0,  0,  3,  0,  1,  4,  0 cannot  be  dis- 
tinguished from  the  sequence  0,  0,  3, 

0,  1,  4,  0,  1 or  any  other  shift  of 
the  basic  pulse  sequence,  since 
carrier  waveform  is  specified  by  the 
relative  position  of  the  pulses  in  a 
sequence.  If  transmissions  are  timed 
relative  to  a system  clock,  shifted 
versions  of  the  same  sequence  can  be 
used  to  specify  different  channels  so 
that  the  number  of  channels  may  be  in- 
creased significantly. 

OPTICAL  NETWORK  ELEMENTS 

The  distribution  of  optical  power  within 
a multi-user  network  requires  that 
several  runctions  be  performed.  Most 
functions  can  be  handled  by  devices 
which  fall  into  three  categories:  drop / 

insert,  branching,  and  mixing.  Numerous 
devices  have  been  proposed  and  many  have 
been  experimentally  evaluated. 

The  simplest  optical  network  elements 
are  the  drop  and  insert  elements.  Drop 
elements  are  characterized  by  having 
one  input  port  and  two  output  ports  and 
are  needed  to  tap  energy  from  the  fiber 
to  supply  a local  receiver.  Insert 
elements  are  characterized  by  having 
two  input  ports  and  one  output  port  and 
are  necessary  to  permit  a user  terminal 
to  launch  its  message  onto  the  fiber. 
Branching  elements  may  be  either 
splitters  or  combiners.  Branch  splitters 
accept  a single  input  and  separate  It 


into  several  outputs;  branch  combiners 
perform  the  inverse  operation  and  have 
several  input  ports  and  a single  out- 
put port.  Mixing  elements  are  the  most 
general  type  of  optical  network  element 
and  are  characterized  by  N input  ports 
and  M output  ports,  the  simplest  mixing 
element  being  the  "Star." 

Optical  network  elements  may  be  grouped 
into  four  categories:  time-wavelength 

invariant,  wavelength  varying,  time 
varying,  and  time-wavelength  varying. 

The  time-wavelength  varying  devices  are 
typically  realized  by  a combination  of 
two  or  more  devices  or  techniques  from 
the  other  three  groups  and  will  not  be 
discussed  separately. 

Time-Wavelength  Invariant  Devices 

A common  four  port  time-wavelength  in- 
variant device  fabricated  in  bulk  form 
is  a simple  beamsplitter.  This  device 
is  a combination  of  a drop  element  and 
an  insert  element.  A similar  device 
could  be  fabricated  in  fiber-compatible 
form  by  polishing  the  ends  of  two  fibers 
on  a 45°  bevel  and  carefully  coating  and 
splicing  them  together. 


Figure  8 illustrates  an  optical  network 
element,  often  referred  to  as  a trans- 
mission star,  which  may  be  used  as  a 
combiner,  splitter  or  mixer  depending 
on  the  number  of  input  and  output  fibers. 
By  using  a mixing  rod  of  sufficient 
length,  signals  injected  at  the  input 
ports  can  be  uniformly  distributed  over 
the  output  ports. 

A drop  element  or  an  insert  element  may 
be  readily  fabricated  by  placing  two  un- 
clad fibers  in  intimate  contact  over  an 
extended  length  as  shown  in  Figure  9. 


Figure  8 - Transmission  Star 


Figure  9 - Drop-Insert  Element  Imple- 
mented With  Distributed  F ibe r- t o- Fibe r 
Coupling 
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The  coupling  efficiency  of  this  device 
is  greatly  improved  with  the  addition 
of  an  index  matching  material  between 
the  fibers.  Using  this  same  principle 
of  operation,  a branching  combiner  or 
splitter  or  a mixer  could  be  constructed 
by  using  three  or  more  fibers. 

Wavelength  Varying  Devices 


voltages  of  several  different  frequencies 
multiple  output  beams  may  be  generated 
creating  a branch  splitter. 

An  alternate  method  for  producing  the 
index  variation  is  with  an  acoustic  field 
The  uses  for  this  device  are  similar  to 
that  employing  e le c t ro-op t 1 c al 1 y induced 
diffraction. 


The  operation  of  wavelength  varying  de- 
vices relies  on  dispersion,  diffraction 
or  interference  effects.  A particularly 
efficient  approach  is  to  use  multilayer 
dielectric  coatings  to  form  a wavelength 
sensitive  mirror.  An  equivalent  approach 
would  be  to  use  a beamsplitter  in  con- 
junction with  a wavelength  selective 
filter.  Devices  of  this  type  are  res- 
tricted to  being  drop  elements. 

A multi-outp  t splitter  may  be  constructed 
by  using  a wavelength  selective  diffracting 
grating  on  the  surface  of  a thinly  clad 
fiber  as  shown  in  Figure  10. ^ A wave- 
length selective  diffraction  grating  could 
also  be  fabricated  using  integrated  op- 
tics. Another  approach  would  be  to  use 
acousto-optic  interactions  to  produce  a 
diffraction  grating.  By  applying  acous- 
tic fields  of  different  frequencies, 
various  optical  wavelengths  could  be 
diffracted  at  different  angles  and  a 
branch  splitter  realized.  With  single 
mode  fibers,  interference  effects  could 
be  used  with  a ring  resonator  to  couple 
power  between  two  closely  spaced  wave- 
guides . 8 


Time  Varying  Devices 

Numerous  techniques  exist  for  implementing 
a time  varying  optical  network  element. 

The  most  attractive  techniques  rely  on 
such  effects  as  acousto-optic,  electro- 
optic, and  magneto-optic  interactions. 


A drop  element  based  on  e le c t ro-op t 1 c 
diffraction  fabricated  in  integrated 
optical  form  is  shown  in  Figure  11. ^ In 
this  device,  a time  varying  voltage  is 
applied  across  interdigital  electrodes 
embedded  in  a thin  film  waveguide.  The 
applied  voltage  generates  a periodic  in- 
dex of  refraction  variation  and  causes  the 
guided  wave  to  be  diffracted.  By  applying 


ciaoo 


OtTICTO*  WITH  OUTPUT  MOPOtTlONAl 
TO  A]  I'GNAi 


CONCLUSION 

Fiber  optic  transmission  offers  an  attrac 
tive  alternative  to  coaxial  cable  for  use 
in  a wideband  multi-user  data  bus  network 
Optical  fibers  are  superior  to  coaxial 
cable  in  terms  of  size,  bandwidth,  and 
immunity  to  electromagnetic  interference. 
Present  fiber  technology  is  sufficiently 
developed  to  permit  replacement  of  many 
coaxial  cable  data  bus  networks  with  an 
equivalent  optical  fiber  system. 

The  design  of  a multi-user  fiber  optic 
data  bus  involves  consideration  of  net- 
work topology,  data  flow  control  proce- 
dures, multiplexing  formats  and  the  opti- 
cal network  elements.  Network  topology 
affects  the  number  of  links  required, 
the  number  of  fibers  per  cable,  and  the 
bandwidth  capacity  required  for  the 
various  links,  which  in  turn  determines 
the  type  of  fiber  that  must  be  used. 
Network  topology  also  determines,  in 
conjunction  with  data  flow  control  pro- 
cedures, such  factors  as  link  set-up 
time,  response  delay,  grade  of  service, 
efficiency,  traffic  congestion,  expanda- 

economics  . 
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Figure  10  - Diffraction  Grating  Deposited 
On  Optical  Fiber  Surface  to  Implement  a 
Drop  Element  or  Splitter 


Figure  11  - Electro-optic  Diffraction 
with  Interdigital  Electrodes  for  Drop 
Element  or  Splitter 
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Multiplexing  affects  the  efficiency  of 
bandwidth  utilization,  the  number  of 
channels  which  may  be  provided  and  the 
grade  of  service.  Optical  fiber  networks 
are  capable  of  accommodating  any  type  of 
multiplexing  format  presently  used  with 
coaxial  cable.  Due  to  the  small  fiber 
size  and  other  waveguide  properties,  opti- 
cal fiber  systems  offer  the  additional 
possibility  of  spatial  multiplexing.  When 
combined  with  conventional  multiplexing 
schemes,  such  as  TDM  and  FDM,  spatial 
multiplexing  offers  considerable  band- 
width potential. 

In  order  to  practically  implement  an  opti- 
cal fiber  network  for  distribution  of 
wideband  information  to  a number  of  users, 
it  is  desirable  to  employ  optical,  rather 
than  electrical,  nodal  network  elements 
such  as  drop  and  insert  elements, 
splitters,  combiners,  and  mixers.  Sev- 
eral techniques  for  implementing  these 
devices  were  illustrated  and  many  have 
already  been  reduced  to  practice.  At 
the  present  rate  of  component  development, 
it  is  likely  that  fiber  optics  will  socn 
play  a key  role  in  wideband  data  bus 
networks . 
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Abstract 

As  advanced  surface  craft  are  designed  and 
developed  to  become  an  integral  part  of  our  sea-borne 
forces,  it  is  imperative  that  they  take  advantage  of  the 
cost  and  weight  savings  that  accrue  from  advanced  data 
and  signal  transfer  systems.  Today  it  is  apparent  that 
the  most  promising  technological  improvements  to  ship- 
board data  communications  are  to  be  achieved  through 
signal  multiplexing.  Paralleling  the  development  of 
shipboard  data  multiplexing  is  the  rapid  development 
and  implementation  of  microprocessor  technology.  The 
Shipboard  Data  Multiplex  System  (SDMS)  promises  to 
allow  an  extremely  beneficial  marriage  of  the  multi- 
plexing and  microprocessing  technologies  which  will 
enhance  many  aspects  of  advanced  surface  craft 
performance. 

I.  Introduction 

It  is  a fact  of  life  that  advances  in  science  and 
technology  breed  on  one  another.  Asa  result,  a pro- 
liferation of  techno-scientific  enterprise  ensues  which 
makes  itself  felt  in  practically  every  facet  of  human 
endeavor.  It  is  no  stranger  to  the  shipbuilding  industry. 
The  competitive  spirit  among  nations  represents  a 
constant  driving  force  to  modernize  existing  shipboard 
subsystems  and  to  expand  ship  performance  by  adding 
new  subsystems  representing  conceptual  innovations. 

The  desire  for  automation  in  view  of  the  many  argu- 
ments for  reduced  crew  manning  also  supplies  pressure 
on  the  shipbuilding  industry  to  further  the  profusion  of 
electronic  modules.  What  we  have  then  are  ships  under- 
going overhaul  and  new  ships  on  the  building  ways  with 
constantly  increasing  technical  complexity.  The  need 
for  communication  amongst  this  broadening  scope  of 
electro'nic  systems  has  made  the  traditional  point-to- 
point  method  of  dedicated  shipboard  wiring  extremely 
cumbersome  (see  Figure  1)  and  expensive.  Total  ship 
system  flexibility  and  survivability  has  been  greatlv 
impacted.  There  is  one  apparent  means  to  cope  with 
the  accelerating  demands  for  data  handling;  this  is 
signal  multiplexing. 


Figure  1.  Traditional  Point-to-Point 
Shipooard  Cabling  (1) 


Signal  multiplexing  can  be  traced  back  to  the  late 
lHOO’s  when  several  telegraph  signals  were  multiplexed 
on  a single  line.  Since  then  multiplexing  has  become  a 
common  means  of  information  transmission.  Today  it 
is  the  traditional  means  of  telephone  transmission  via 
coaxial  cable  and  microwave  broadcast.  It  has  been 
adapted  for  use  aboard  commercial  aircraft  and  is  in 
broad  use  in  industrial  process  monitoring  and  control. 
On  advanced  surface  craft  where  weight  is  a critical 
factor,  multiplexing  is  inevitable.  This  weight  savings 
can  translate  into  greater  fuel  capacity  for  increased 
endurance,  increased  weaponry  or  a higher  level  of 
instrumentation  and  monitoring  to  enhance  performance 
objectives. 

II.  Multiplexing  With  SDMS 

The  Shipboard  Data  Multiplex  System  (SDMS)  is  a 
general  purpose,  asynchronous  data  communications 
system  having  distributed  redundancy  and  self-auditing 
features.  It  is  designed  to  handle  the  data  transfer 
requirements  of  practically  all  shipboard  subsystems; 
e.g. , weapon  direction  systems,  command  and  control 
consoles,  displays,  damage  control  central,  navigation, 
interior  communications,  and  machinery  control  func- 
tions. Miles  of  dedicated  cabling  will  be  replaced  with 
hundreds  of  feet  of  general  purpose  coaxial  cable. 

Numerous  different  modular  partitionings  of  the 
SDMS  hardware  are  envisioned  in  the  future,  dependent 
on  data  loads  and  standard  interface  developments  for 
shipboard  subsystems.  Currently,  however,  a basic 
architecture  has  been  developed  lor  the  advanced  devel- 
opment model  (ADM)  of  the  SDMS.  The  ADM  SDMS  was 
delivered  in  the  spring  of  1976  to  the  Naval  Electronics 
Laboratory  Center,  San  Diego,  where  it  is  undergoing 
development  test  and  evaluation  (DT&E). 

The  ADM  SDMS  consists  of  three  primary  elements 
which  perform  the  active  operational  functions  of  SDMS. 
These  are: 

Traffic  Control  Unit  - TCU 

Area  Multiplexer  - AM 

Remote  Multiplexer  - RM 

Additionally,  SDMS  incorporates  a maintenance  unit 
(MU),  input/output  units  (IOU)  for  signal  conversion, 
and  primary  data  buses.  Stub  cables  and  isolation  taps 
are  also  part  of  the  system. 

SDMS  Operation 

SDMS  architecture  is  shown  in  Figure  2. 

Five  primary  data  buses  are  shown  which  represent 
the  number  of  cables  envisioned  for  a CGN  or  CVN 
application  allowing  a large  data  load  and  a high  degree 
of  redundancy.  A quantity  of  seven  Area  Multiplexers 
(AM  s)  and  17  Remote  Multiplexers  (RM  s)  is  represen- 
tative of  the  number  of  system  elements  appropriate  to 
the  interior  communication  subsystem  of  a CGN. 

Figure  2 illustrates  growth  capacity  to  16  AM’s  and 
112  RM’s. 
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Figure  2.  SDMS  Architecture 


A sink  or  user  subsystem  A desiring  information  is 
connected  to  a remote  multiplexer  (RM)  which  formulates 
a request  and  codes  it  as  a time  division  multiplexed 
signal.  The  request  contains  the  address  of  the  remote 
multiplexer  connected  to  the  information  source  subsys- 
tem B.  The  request  is  sent  by  the  RM  to  a local  area 
multiplexer  (AM)  which  converts  the  request  into  FDM 
language  for  passage  over  a primary  bus  cable.  The  AM 
transmits  the  request  when  one  of  the  traffic  control 
units  (TCI')  provides  an  idle  channel.  The  request  is 
received  by  the  AM  local  to  the  source  subsystem.  The 
source  AM  converts  the  request  to  TDM  language  and 
passes  it  to  the  spurce  RM.  The  source  RM  assembles 
samples  of  the  dtjsired  signals  in  TDM  language  and 
passes  them  to  tec  source  AM  where  they  are  converted 
to  FDM  language.  The  signal  information  then  travels 
back  through  the  primary  data  bus  channel  to  the  sink 
subsystem  via  the  sink  AM  and  RM,  and  FDM  to  TDM 
conversion.  An  input  output  module  in  an  input  output 
unit  associated  with  the  sink  RM  converts  the  signal 
information  from  TDM  language  to  subsystem  format 
(discrete,  digital,  synchro,  etc). 

SDMS  C ont rol 


Each  main  bus  is  a coaxial  cable  used  as  a frequency 
modulated-RF  transmission  line.  Five  center  frequen- 
cies ranging  from  approximately  40  MHz  to  80  MHz  arc 
used  as  carriers  on  each  bus  cable.  Each  center 
frequency  is  modulated  to  provide  a 1. 2M  bits /sec  data 
rate.  Four  of  the  center  frequency  carriers  are  used 
as  data  channels  while  the  fifth  is  used  for  traffic 
control  purposes.  This  arrangement  provides  4.  8M 
bits/sec  of  gross  data  capacity  per  cable  and  24M  bits 
sec  gross  capacity  for  a five  cable  system.  The 
primary  data  buses  are  terminated  with  their  charac- 
teristic impedance  to  minimize  reflections  and  are 
tapped  with  passive,  fully  matched  Isolation  taps. 
Independency  is  maintained  between  the  primary  data 
buses  such  that  a short  or  open  circuit  on  one  bus  will 
not  interfere  with  data  transmission  on  any  of  the 
remaining  buses,  location  of  the  isolation  taps  may 
be  at  any  point  along  a primary  data  bus. 

Actual  operation  of  the  SDMS  is  simple.  It  has 
distributed  control  and  uses  time  division  multiplexing 
(TDM),  frequency  division  multiplexing  (FDM)  and 
space  division  multiplexing.  Referring  to  Figure  3,  a 
typical  data  transfer  can  be  traced. 


Figure  3.  SMDS  Data  Transfer  ^ 


Control  of  the  data  transfer  process  is  vested  in 
two  programmable  read-only  memories  (PROM's).  One 
PROM  is  located  with  each  of  the  two  RM  s involved  In 
a data  exchange.  No  central  or  clock  synchronized 
control  is  involved;  control  is  distributed.  The  distri- 
buted control  approach  allows  the  establishment  of  data 
paths  between  user  subsystems  locally.  The  RM  PROM's 
contain  the  data  transfer  parameters  - addressing, 
priority,  periodicity  - for  a given  data  exchange. 
Establishment  of  a data  link  simply  requires  coding  of 
the  receiving  and  transmitting  PROM  's  and  insertion  of 
these  PROM  s into  plug-in  slots  in  the  sink  and  source 
RM's.  Insertion  of  appropriate  standardized  input/ 
output  modules  in  the  sink  and  source  input  output  units 
is  also  required.  Alterations,  additions  or  deletions  of 
interconnectivity  patterns  or  data  exchange  character- 
istics can  be  made  by  simply  inserting  new  PROM's  with 
appropriately  coded  data  parameters  in  the  RM  's  asso- 
ciated with  the  specific  subsystems  involved.  Errors  in 
making  alterations  to  given  subsystem  data  exchange 
characteristics  have  no  effect  on  data  exchange  betw  een 
subsystems  not  involved  in  the  alteration  process.  The 
distributed  contiol  feature  allows  changes  to  be  made 
simply,  with  low  cost  and  without  disastrous  effect  on 
total  shipboard  operation  when  errors  are  made.  Dis- 
tributed control  also  provides  for  "free-running," 
asynchronous  operation  independent  of  a central  control 
authority  which  could  precipitate  catastrophic  failure. 

Asynchronous  operation  can  efficiently  handle 
periodic  and  aperiodic  signals  alike  with  wide  choice  of 
update  rates.  This  is  in  sharp  contrast  to  a synchronous 
system  having  fixed  time  slots,  sequenced  together  in 
a rigid  chain,  under  control  of  a central  clock  subject  to 
a common  failure-mode.  SDMS  asynchronous  operation 
is  independent  of  software  programming.  All  program- 
ming is  hardwired  in  the  PROM  's  and  is  distributed  so 
that  authority  over  any  specific  interconnection  is  vested 
in  only  two  PROM's.  Multiplexing  systems  dependent 
on  software  control  must  await  completion  of  overall 
system  design  before  software  requirements  can  be 
finalized.  Further  delay  is  encountered  in  program 
debugging.  The  distributed  control,  asynchronous  SDMS 
is  free  of  these  problems.  Subsystems  can  be  added  to 
or  deleted  from  the  system  at  any  time  with  no  effect  on 
data  exchange  between  other  subsystems  on  the  network. 
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Principle  SDMS  Elements 

Active  operation  of  the  SDMS  is  modularly  divided 
between  the  traffic  control  units,  area  multiplexers  and 
remote  multiplexers.  Combined  with  the  primary  and 
stub  multiplex  cables,  these  three  elements  perform 
all  operational  functions  of  this  extremely  flexible, 
asynchronous  multiplexing  system. 


digital  and  discrete  user  signals  may  be  plugged 
randomly  into  any  of  the  G4  slots.  These  plug-in  slots 
are  not  dedicated  to  conversion  of  any  particular  signal 
type;  their  application  is  universal.  For  the  ADM 
SDMS,  13  I/O  modules  were  developed  for  standard 
format  conversion  of  existing  shipboard  signal  types. 
As  the  need  arises,  further  I/O  modules  will  be 
developed. 


Traffic  Control  Unit 

Dedicated  to  each  primary  data  bus  is  a traffic 
control  unit  which  operates  asynchronously  and  inde- 
pendently of  all  others.  Each  TCll  monitors  traffic  on 
its  primary  bus  and  upon  detecting  an  idle  data  channel 
offers  Its  use  via  a polling  sequence  to  the  AM's.  An 
AM  requesting  service  will  accept  the  offer.  Following 
acceptance  of  the  offer  the  TCU  will  continue  to  scan 
for  idle  channels  and  make  offers  to  requesting  AM's 
via  the  polling  sequence. 

Area  Multiplexer 

The  area  multiplexer  provides  a common  interface 
to  the  multiplexing  system  for  all  of  the  RM's  it  ser- 
vices, thus  minimizing  the  number  of  line  taps  to  the 
primary  data  buses.  AM's  are  capable  of  simultane- 
ously transmitting  or  receiving  from  each  of  the  primary 
data  buses.  Using  an  RM  flag  and  queuing  register,  an 
AM  will  provide  primary  data  bus  access  to  the  RM 
with  the  highest  priority  service  request.  However, 
there  will  be  no  lock-up  mode  because  the  priority 
queuing  registers  are  aisotimed  out.  Each  AM  is  func- 
tionally doubly  redundant;  i.e. , there  are  two  independ- 
ent halves  or  sections  as  shown  in  Figure  4.  Separate 
cable  stubs  connect  each  half  of  the  AM  to  the  primary 
buses  through  dual  isolation  taps.  Each  half  of  the  AM 
Is  polled  separately  by  the  TCU  thereby  maintaining 
full  AM  redundancy. 


20  PATHS 

AM  TO  AM 


A PATHS 
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Figure  4.  SDMS  Redundancy 
Remote  Multiplexer 


The  RM  is  divided  into  dual-redundant  sections 
called  shared  electronics  (SE).  Each  of  the  I/O  modules 
has  access  to  either  of  the  dual- redundant  sections. 
Characteristics  of  subsystem  data  requests  are  stored 
in  PROM's  within  each  SE.  Addition  or  replacement  of 
a subsystem  on  the  SDMS  network  is  a simple  matter  of 
inserting  appropriate-  I/O  modules  and  appropriately 
coded  PROM'S  in  the  source  and  sink  RM's  associated 
with  the  new  or  revised  data  path.  SE  selection  logic 
establishes  one  of  four  possible  AM  paths  (see  Figure  4) 
for  transmittal  of  the  highest  priority  message  on  a 
random  first-come,  first-served  basis.  The  selection 
logic  does  not  involve  any  external  monitor  and  control 
decision  elements  which  could  produce  a single-point 
failure. 

Maintenance  Unit 

Performance  verification,  fault  localization  and 
configuration  monitoring  functions  are  performed  by  the 
maintenance  unit.  The  performance  verification  function 
is  performed  automatically  without  interruption  of  SDMS 
data  flow  and  does  not  require  operator  action.  Redun- 
dant sections  of  the  AM's  and  RM’s  are  monitored  sep- 
arately by  the  MU  in  addition  to  TCU's,  IOU's,  primary 
buses,  tap  stubs  and  secondary  multiplex  cables.  A 
minicomputer  within  the  MU  analyzes  collected  input 
data  and  determines  the  Line  Replaceable  Unit  (LRU) 
within  a TCU,  AM,  RM,  or  IOU  causing  an  indicated 
malfunction.  The  diagnostic  test  routine  is  initiated 
automatically  upon  detection  of  a fault  and  the  resultant 
fault  localization  data  are  printed  out.  Manual  override 
of  the  automatic  fault  localization  feature  is  permitted 
to  allow  manual  troubleshooting.  The  MU  also  includes 
a self-test  feature  via  internal  BITE  circuitry.  Config- 
uration monitoring  is  provided  by  the  MU  in  the  form  of 
a system  interconnectivity  list  on  a hardcopy  printout 
or  a magnetic  tape  recording.  Readout  of  the  SE 
memory  PROM's  provides  system  interconnectivity  as 
a "From-To"  list  somewhat  akin  to  a standard  ship's 
wiring  list. 

The  Ml'  interfaces  with  the  primary  buses  in  a 
manner  similar  to  an  AM,  Figure  2.  Passive  channel 
requests  preveni  an  MU  failure  from  having  an  effect 
upon  operations  data  transfer.  Failure  of  an  MU  will 
simply  impair  . e process  of  rapid  fault  localization. 
Data  transfer  w .11  continue  to  take  place  as  long  as  one 
of  the  multiple  redundant  paths  of  communication 
between  specific  communicating  subsystems  remains 
intact. 


The  remote  multiplexer  and  the  input/output  units 
can  be  located  in  the  same  cabinet  (depicted  In  Figure  4) 
or  they  can  be  isolated  as  separate  units  (Figure  3) 
depending  on  system  application  and  configuration 
requirements. 

Subsystem  access  to  the  SDMS  is  via  the  RM.  A 
standard  format  is  established  by  the  IOU  for  user 
signals  transmitting  to  and  from  the  SDMS.  There  can 
be  up  to  four  separable  IOU's  with  10  I/O  module  slots 
per  IOU;  a maximum  of  (!4  slots  per  RM  is  available. 

An  I/O  module  for  conversion  of  analog,  synchro, 


111.  SDMS  for  an  Advanced  Surface  Craft 

As  an  example  of  an  SDMS  application,  a vehicle 
gencrlcally  in  the  Advanced  Surface  Craft  (ASC)  cate- 
gory will  be  examined  as  a candidate  platform  for  SDMS 
Installation.  For  an  ASC  having  a length  of  approxi- 
mately 200  ft.  It  is  estimated  that  25,500  ft  of  polnt-to- 
peint  dedicated  able  would  be  needed  to  interconnect 
the  subsystems  This  estimate  was  determined  from  a 
layout  of  a sp-.  be  hydrofoil  craft.  Using  an  equipment 
summary  of  the  hydrofoil,  the  point-to-point  distance 
along  horizontal  and  vertical  straight  lines  connecting 
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the  appropriate  subsystems  was  determined.  In  total, 

20ti  interconnecting  cables  were  identified.  Fifty  feet 
was  added  to  each  of  the  cables  to  account  for  the 
unlikelihood  of  achieving  direct,  point-to-point  connec- 
tions. An  additional  30  percent  allowance  was  added 
to  the  estimated  cable  length  to  provide  for  terminations. 

Table  1 gives  a tabulation  of  SDMS  hardware 
requirements  for  this  particular  ASC  providing  a com- 
parison with  the  point-to-point  requirement.  The  SDMS 
requirements  resulted  from  an  analysis  of  signal 
loading  and  physical  layout.  It  was  decided  that  a single- 
stage  system  (AM  and  RM  functions  combined  into  a 
single  data  terminal)  would  be  more  than  adequate  for 
this  application.  Three  main  bus  cables  were  adopted 
running  longitudinally  in  the  ship.  The  main  buses  were 
sized  at  100  ft  to  run  from  the  forward  part  of  the  ship 
to  a termination  point  somewhat  short  of  the  ship's  stem. 
The  foreshortened  aft  end  termination  was  dictated  by 
the  economics  of  the  situation.  Data  capacity  require- 
ments in  the  ship's  after  section  required  the  use  of  only 
one  data  terminal  (DT).  Thus  the  use  of  longer  than 
average  stub  cables  to  connect  this  DT  to  the  main  buses 
was  chosen  in  place  of  longer  bus  cables. 


Table  1.  Comparison  of  SDMS  and  Traditional 
Hardware  for  a Candidate  Advanced  Surface  Draft 


SDMS 

Cabling 

• 

6 Data  Terminals 

• 

3 Traffic  Control  Units 

• 

1 Maintenance  Unit 

• 

Bus  Cables,  3 x 100  ft 

300  ft 

• 

Stub  Cables,  21  Paths  (C  DT's  and  1 MU  paralleled  to  3 buses) 
33  ft  Average  Path  Length,  21  x 33  ft  = 693  ft 

693  ft 

• 

OT's  to  User  Terminations,  206  Subsystem  Interconnections 
with  Source  and  Termination  Hookups,  27.5  ft  Average 
Length,  206  x 27.5  ft  = 5,665  ft 

5,665  ft 

Total  SDMS  Cabling 

6,658  ft 

Traditional  Cabling 

• 

Pointto-Point  Dedicated  Cabling 
(206  Subsystem  Interconnections) 

25,500  ft 

Each  of  six  DT's  and  the  MU  connects  to  each  of 
the  three  main  buses  for  a total  of  21  stub  cable  runs 
with  an  average  length  of  33  ft.  This  yields  a require- 
ment for  approximately  693  ft  of  stub  cable.  Each  of 
the  206  subsystem  interconnections  requires  an  average 
27.  5 ft  cable  hookup  to  both  the  source  and  sink  DT's 
combined.  Approximately  5,665  ft  of  cable  is  required 
between  the  user  subsystems  and  the  six  DT's.  The 
total  SDMS  cable  requirement  is  shown  to  be  approxi- 
mately 6,660  ft.  The  traditional  point-to-point  dedicated 
cable  requirement  is  25,500  ft,  or  18,840  ft  more  than 
the  SDMS  requirement. 

An  analysis  of  information  flow  rate  required  by 
the  ASC  yielded  an  estimate  of  120K  bits/sec  (bps). 

This  analysis  considered  that  certain  signals  would  not 
be  handled  by  the  SDMS,  e.  g. , unprocessed  audio  and 
video  signals.  Signals  of  this  nature  might  originate 
as  sonar  audio  or  radar  video.  Among  those  signals 
to  be  carried  by  the  SDMS,  12  bits  were  allotted  per 
analog  signal  (sign  bit  plus  one  part  in  2000  resolution) 
and  12  bits  per  cyclic  speed  of  synchro  signal  (five  arc 
minutes  resolution  per  one-speed  synchro  cycle). 

Signal  update  rates  of  1,  20  or  30  times  per  second  were 
used.  The  resulting  120K  bps  transfer  rate  does  not  tax 
even  one  primary  bus  cable.  However,  three  primary 
buses  were  included,  in  spite  of  the  relatively  low  data 
rate,  to  provide  the  high  reliability  inherent  in 
redundancy. 


Table  2 shows  a weight  comparison  between  an 
SDMS-type  multiplex  system  and  the  traditional  dedicated 
point-to-point  cabling  for  our  candidate  ASC.  The 
weight  comparison  includes  only  those  items  listed  and 
excludes  such  things  as  taps,  brackets,  cable  trays, 
maintenance  unit  and  switchboards.  The  weight  numbers 
for  the  SDMS  components  in  Table  2 are  known  from 
currently  existing  hardware.  For  traditional  cabling,  a 
weight  of  0.  6 lb/ft  was  used  based  on  an  average  of 
wt 'ft  values  for  several  types  of  shipboard  cabling.  The 
net  weight  savings  using  the  SDMS  is  approximately 
10,000  lb. 

Table  2.  SDMS  vs  Traditional  Cabling 
Weights  for  an  ASC 


Components 

Unit  Weight  (Ib/Ueeit) 

Tout  Wft|ht(lb) 

SDMS 

6 Data  Terminals 

275 

1,650 

(Including  all  lOU's) 

3 TCU's 

20 

60 

300  ft  bus  Cable 

0.446 

130 

663  ft  Stub  Cable 

0.201 

140 

5,665  ft  Termination  Cable 

0.60 

3,400 

Total  SDMS 

5,380 

Traditional 

25,500  ft  Dedicated  Cable 

0.60 

15,300 

If  an  installed  cable  cost  figure  of  $35/ft  is  assumed, 
the  savings  resulting  solely  from  the  18,  840  ft  of  elimin- 
ated cable  amounts  to  approximately  $660, 000.  This 
cost  savings  results  entirely  from  the  rediuced  SDMS 
cabling  requirements  on  new-build  ASC  vehicles,  but 
does  not  include  the  cost  of  SDMS  hardware.  The  rela- 
tive savings  during  overhauls  is  sharply  increased  in 
favor  of  the  SDMS,  since  subsystems  serviced  by  the 
SDMS  will  at  most  require  connection  to  a nearby  RM. 
Long  lengths  of  new  cabling  or  labor  intensive  cable 
pulling  will  not  be  required. 

IV.  Multiplexing  and  Microprocessors 

The  recent  development  of  microprocessors  comes 
at  a time  when  the  centralized  shipboard  computing 
facility  concept  has  begun  to  exhibit  some  of  its  faults. 
For  those  subsystems  which  are  dependent  upon  contin- 
uous computer  servicing,  the  failure  of  a central  com- 
puter often  means  simultaneous  downtime  for  the 
subsystem. 

Favorable  size  and  cost  aspects  of  microprocessors 
are  providing  design  engineers  with  the  impetus  to  per- 
form critical  data  processing  within  the  confines  of  the 
user  subsystem,  thus  decoupling  dependent  subsystems 
from  the  simultaneous  casualty  mode  of  a central 
computer  failure.  The  development  of  shipboard  data 
multiplexing  at  the  time  of  introductory  practical  appli- 
cations of  microprocessors  has  resulted  in  a synergistic 
affair.  RF  data  multiplexing  greatly  increases  informa- 
tion transfer  efficiency  over  dedicated,  point-to-point 
wiring  methods.  However  the  bandwidth  of  RF  systems 
does  have  a finite  limit.  Using  microprocessors,  the 
bulk  of  data  processing  can  be  performed  within  the 
user  subsystem.  The  data  to  be  carried  over  the  multi- 
plex cables  can  often  be  reduced  to  command,  control 
and  monitoring  functions  with  a much  lower  data  rate 
requirement.  The  dependence  on  centralized  computing 
is  diminished  and  integrated  shipboard  system  reliability 
is  enhanced. 

Electronic  systems  aboard  ships  have  varying 
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electronic  signal  interface  formats.  For  signal  infor- 
mation transfer  over  a multiplex  system,  it  is  desirable 
to  convert  the  various  signal  formats  to  a common 
multiplex  system  format.  This  format  or  language 
conversion  is  easily  handled  by  microprocessors  in  the 
input/ output  stage  of  the  multiplex  system.  Some 
sensory  devices  do  not  readily  accommodate  data 
processing  electronics.  Consider  physically  small 
accelerometers  which  might  be  used  for  noise  and  vibra- 
tion monitoring  (NVM).  The  sensed  signal  might  best 
be  routed  to  the  multiplexer  input/output  stage  where 
microprocessors  using  fast  fourier  transform  algorithms 
can  decipher  the  signal  characteristics.  Once  the  raw 
data  are  reduced  to  extract  the  desired  information,  the 
data  load  placed  on  the  multiplex  system  is  minimized. 

It  is  not  difficult  to  foresee  a continually  evolving  happy 
marriage  between  shipboard  data  multiplexing  and 
microprocessing.  The  Shipboard  Data  Multiplex  System 
(SDMS)  incorporates  the  advantages  inherent  in  multi- 
plexing and  microprocessing  technology,  and  provides 
the  shipbuilding  industry  a superlative  means  to 
capitalize  on  these  developments. 

V.  Benefits  with  SDMS  Multiplexing 

SDMS  is  designed  to  provide  multiple  redundant 
transmission  paths.  A path  between  two  high  priority 
users  can  be  channeled  (see  Figure  4)  from  the  JOU  to 
two  SE  sections  to  four  AM  sections,  each  of  which  is 
paralleled  to  five  primary  buses  in  the  large  ship 
system.  The  process  is  reversed  at  the  other  term- 
inus of  the  data  exchange  path.  The  number  of  paths 
increases  by  a factor  of  n at  each  stage  where  n paths 
parallel  each  other.  Further  redundancy  can  also  be 
obtained  by  connecting  user  subsystems  to  more  than 
one  I/O  module  or  to  multiple  RM's.  Using  a one- 
hour  mean-time-to-repair,  a 0.999  999  999  9 
availability  is  achieved  by  the  ADM  SDMS  configuration. 

The  high  level  of  redundancy  in  SDMS  provides 
"graceful  degradation"  in  the  presence  of  increasing 
path  failures.  As  one  path  fails,  e.  g. , due  to  an  AM 
failure,  another  path  takes  over  the  routing  through  a 
redundant  system  element.  Even  main  bus  failures 
are  not  catastrophic.  As  long  as  one  main  bus  remains, 
data  transfer  will  continue  although  the  maximum  up- 
date rate  of  periodic  data  transfer  will  be  slightly 
reduced.  Access  time  to  the  main  bus  will  be  increased 
as  more  traffic  competes  for  use  of  the  limited  bus 
resource. 

SDMS  offers  improved  flexibility  in  new  construc- 
tion and  overhaul  shipbuilding.  Ship  design  is  simplified 
with  less  cable  layout.  Fewer  switchboards,  mounting 
brackets  and  bulkhead  penetrations  are  required.  Sub- 
system or  equipment  changes  are  easily  facilitated  late 
in  the  shipbuilding  schedule.  There  is  no  requirement 
to  reroute  existing  or  add  new  cabling.  Subsystem 
changes  during  overhauls  are  handled  by  changes  in 
I/O  module  mix,  user  PROM's,  the  number  of  lOU's 
and  possibly  the  number  of  RM's.  More  frequent 
modernizations  are  accommodated  to  achieve  a higher 
degree  of  operational  effectiveness. 


Multiplexing  facilitates  improved  ship  system 
monitoring.  With  most  shipboard  data  traveling  on 
several  primary  bus  lines,  these  lines  can  be  tapped  to 
allow  data  readout  at  several  strategically  located 
terminals.  Terminals  in  the  wardroom,  bridge  or 
Captain’s  stateroom  can  be  connected  to  the  main  bus  In 
a manner  similar  to  an  AM.  An  interactive  display  can 
be  installed  at  such  terminal  locations  with  readout 
formatting  provided  by  microprocessors  internal  to  the 
display  module.  Different  display  "pages”  can  be  made 
available  upon  local  command.  One  can  envision  mainte- 
nance data  being  supplied  as  display  pages  to  the  engine 
room,  CIC  or  other  data  intense  compartment  via  SDMS 
and  an  interactive  display.  A tighter,  more  responsive 
operating  unit  can  be  anticipated. 

Undoubtedly,  the  implementation  of  shipboard  multi- 
plexing will  spawn  new  concepts  for  its  further  applica- 
tion. Data  rate  capacity  requirements  will  increase. 

The  use  of  fiber  optics  for  increased  bandwidth  must  be 
investigated.  Fiber  optic  materials  presently  exist  with 
losses  as  low  as  1 to  2 dBAm  in  the  1. 0 to  1. 1 micron 
region.  (2)  Additionally,  double  heterojunction,  light 
emitting  and  laser  diode  sources  are  under  development 
with  continuous  output  power  of  several  Mw  and  modu- 
lation rates  of  hundreds  of  MHz.  A new  world  of 
possibilities  is  brewing  for  shipboard  communications. 

VI.  Summary 


Shipboard  data  multiplexing  offers  many  advantages 
over  conventional  point-to-point  wiring  schemes.  Cost 
and  weight  advantages  go  hand-in-hand  and  are  very 
apparent  in  this  developing  technology.  The  reduced 
weight  advantage  is  particularly  appropriate  to  advanced 
surface  craft.  The  implementation  of  microprocessor 
technology  is  quite  timely  to  the  application  of  multi- 
plexing in  sliipboard  data  transfer  and  promises  to  keep 
the  multiplexing  data  load  manageable.  Asynchronous 
operation,  multiple  redundancy  and  distributed  control 
with  SDMS  provide  for  extreme  flexibility,  graceful 
degradation  and  10  nines  availability.  Room  for  growth 
is  a built-in  feature  of  the  SDMS  technique  while  advance- 
ments in  the  technology  of  fiber  optic  communications 
promise  to  allow’  even  further  capacity  growth.  The 
inevitability  of  shipboard  internal  communications  via 
data  multiplexing  is  obvious. 
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1.  SCOPE  AND  PURPOSE 

1.1  Scope.  This  standard  defines  requirements  for  digital,  command/ 
response,  time  division  multiplexing  (Data  Bus)  techniques  on  aircraft. 

It  'encompasses  the  data  bus  line  and  its  interface  electronics  as  illustrated 
on  figure  1,  and  also  defines  the  concept  of  operation  and  information 
flow  on  the  multiplex  data  bus  and  the  electrical  and  functional  formats 
to  be  employed. 

1.2  Purpose.  The  purpose  of  this  document  is  to  establish  uniform 
requirements  for  multiplex  data  system  techniques  which  will  be  utilized 
in  systems  integration  of  aircraft  subsystems  and  to  promote  standard 
digital  interfaces  for  associated  subsystems.  The  system  designer  retains 
the  flexibility  to  assemble  a custom  multiplex  system  from  the  functionally 
standard  parts  and  to  program  the  standard  electronic  functions  in  order 

to  provide  a control  mechanism,  traffic  patterns,  redundancy,  and  a viable 
degradation  concept. 

2.  APPLICABLE  DOCUMENTS 

2.1  The  following  documents,  of  the  issue  in  effect  on  date  of  invitation 
for  bid  or  request  for  proposal,  form  a part  of  the  standard  to  the  extent 
specified  herein. 

SPECIFICATION 


Electromagnetic  Compatibility  Requirements,  Systems 


Electromagnetic  Interference  Characteristics,  Requirements 
for  Equipment 

Electromagnetic  Interef erence  Characteristics,  Measurement  of 


(Copies  of  specifications,  standards,  drawings,  and  publications  required 
by  suppliers  in  connection  with  specific  procurement  functions  should  be 
obtained  from  the  procuring  activity  or  as  directed  by  the  contracting 
officer . ) 

FSC  MISC 
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3.  DEFINITIONS 

3.1  Remote  terminal.  The  remote  terminal  Is  the  electronics  necessary 
to  interface  the  bus  with  the  subsystem  and  the  subsystem  with  the  bus. 

This  electronics  may  exist  as  a separate  LRU  (line  replaceable  unit), 

or  be  contained  within  the  users'  subsystem.  A redundant  bus  controller, 
when  not  functioning  as  a controller,  may  operate  as  a remote  terminal. 

3.2  Bit . Contraction  of  binary  digit:  may  be  either  zero  or  one.  In 

information  theory  a binary  digit  is  equal  to  one  binary  decision  or  the 
designation  of  one  of  two  possible  values  or  states  of  anything  used  to 
store  or  convey  information. 

3.3  Bit  rate.  The  number  of  bits  transmitted  per  second. 

3.4  Pulse  code  modulation  (PCM).  The  form  of  modulation  in  which  the 
modulation  signal  is  sampled,  quantized,  and  coded  so  that  each  element 

of  information  consists  of  different  types  or  numbers  of  pulses  and  spaces. 

3.5  Time  division  multiplexing  (TDM) . The  transmission  of  information 
from  several  signal  channels  through  one  communication  system  with  different 
channel  samples  staggered  in  time  to  form  a composite  pulse  train. 

3.6  Command/response  mode.  The  operation  of  a bus  system  in  which  the 
remote  terminal  will  respond  only  when  commanded  by  the  bus  controller. 

3.7  Half  duplex.  Operation  of  a data  transfer  systpm  in  either  direction 
over  a single  line,  but  not  in  both  directions  on  that  line  simultaneously. 

3.8  Asynchronous  operation.  For  the  purpose  of  this  standard,  asynchronous 
bus  operation  impli®  an  independent  clock  source  at  each  remote  terminal 
which  is  utilized  for  the  transmission  of  messages.  The  received  message 
shall  be  decoded  using  clock  information  derived  from  the  received  signal. 

3.9  Dynamic  bus  allocation.  The  operation  of  a bus  system  in  which 
designated  remote  terminals  are  offered  control  of  the  data  bus. 


3.10  Word . In  this  document  a word  is  a sequence  of  16  bits  plus  sync 
and  parity.  There  are  three  types  of  words:  command,  status  and  data. 
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5.11  Message . A message  is  a transmission  of  words  on  the  data  bus  cable. 

\ message  transfer  is  complete  when  the  command  word, data  word (s)j  and  the 
status  word  have  been  transmitted.  There  are  three  types  of  messages: 
controller  to  terminal,  terminal  to  controller  and  terminal  to  terminal. 

3.12  Data  bus.  Whenever  a data  bus  or  bus  is  referred  to  in  this  document 
It  shall  imply  a single  twisted  shielded  pair  cable. 

'3  Coat  roller.  The  controller  shall  be  a unit  that  is  either  programmable, 
'ontrolled  by  a processor,  and  that  serves  the  function  of  commanding, 

"ning  and  monitoring  bus  traffic. 

4.  REQUIREMENTS 

4.1  Data  bus  operation.  The  multiplex  data  bus  in  its  most  elemental 
configuration  shall  operate  as  shown  on  figure  1.  The  data  bus  shall 
function  asynchronously  in  a command /response  nude,  and  transmission  snail 
occur  in  a half-duplex  manner.  Sole  control  of  information  transmission 
on  the  bus  shall  reside  with  the  bus  controller,  which  shall  initiate  all 
transmissions.  The  information  flow  on  the  data  bus  shall  be  comprised 

of  messages  which  are,  in  turn,  formed  by  three  types  of  words  (command, 
data,  and  status)  as  defined  in  4. 2. 3. 5.  All  elements  of  the  data  bus, 
including  the  transmission  line,  remote  terminal  and  controller,  shall 
conform  to  the  electromagnetic  interference  requirements  specified  in 
MIL-STD-461  and  the  electromagnetic  compatibility  requirements  of  MIL-E-6051. 

4.1.1  Information  transfer  modes.  The  d,ata  bus  may  employ  three  modes  of 

information  transfer:  (1)  bus  controller  to  remote  terminal  (RT)  transfer, 

(2)  RT  to  controller  transfer,  and  (3)  RT  to  RT  transfer.  These  modes  shall 
operate  as  described  in  4. 2. 3. 6 and  subparagraphs. 

4 . 2  Characteristics. 

4.2.1  Data  form.  Digital  data  may  be  transmitted  in  any  desired  form, 
provided  that  the  chosen  form  shall  be  compatible  with  the  message  and 
word  formats  defined  in  this  standard.  Any  unused  bit  positions  in  a 
word  shall  be  transmitted  as  logic  zeros. 

4.2.2  Bit  priority.  The  most  significant  bit  shall  be  transmitted  first 
with  the  less  significant  bits  following  in  descending  order  of  value.  The 
number  of  bits  required  to  define  a quantity  shall  be  consistent  with  the 
resolution  or  accuracy  required.  In  the  event  double  precision  quantities 
(information  accuracy  or  resolution  requiring  more  than  16  bits)  are 
transmitted,  the  more  significant  half  shall  be  transmitted  first, 
followed  by  the  less  significant  half. 
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4.2.3  Transmission  method. 

4. 2. 3.1  Modulation.  The  signal  shall  be  transferred  over  the  data 
bus  in  serial  digital  pulse  code  modulation  form. 

4. 2.3. 2 Data  code.  The  data  code  shall  be  Manchester  bi-phase  level. 

A logic  one  shall  be  transmitted  as  a bipolar  coded  signal  1/0  (i.e., 

a positive  pulse  followed  by  a negative  pulse).  A logic  zero  shall  be  bipolar 
coded  signal  0/1  (i.e.,  a negative  pulse  followed  by  a positive  pulse).  A 
transition  through  zero  occurs  at  the  midpoint  of  each  bit  time  (see 
figure  2). 

4. 2. 3. 3 Transmission  rate.  The  transmission  rate  on  the  bus  shall  be 
1.0  megabit  per  second  with  a long  term  stability  of  +0.01  percent  (i.e., 

+100  Hz).  The  short  term  stability  (i.e.,  stability  over  a 1.0  second 
interval)  shall  be  at  least  0.001  percent  (i.e.,  +10  Hz). 

4. 2. 3.4  Word  size.  The  word  size  shall  be  16  bits  plus  the  sync  waveform 
and  the  parity  bit  for  a total  of  20  bit  times  as  shown  in  figure  3. 

4. 2. 3. 5 Word  formats.  The  word  formats  shall  be  as  shown  on  figure  3 
for  the  command,  data,  and  status  words. 

4. 2. 3. 5.1  Command  word . A command  word  shall  be  comprised  of  a sync 
waveform,  address,  transrait/receive  bit,  subaddress/mode,  data  word  count, 
and  a parity  bit  (see  figure  3),  except  as  modified  by  4. 2. 3. 5. 1.7. 

4. 2. 3. 5. 1.1  Sync.  The  command  sync  waveform  shall  be  an  invalid  Manchester 
waveform  as  shown  on  figure  4.  The  width  shall  be  three  bit  times,  with 

the  waveform  being  positive  for  the  first  one  and  one-half  bit  times, 
and  then  negative  for  the  following  one  and  one-half  bit  times.  If  the  next 
bit  following  the  sync  is  a logic  zero,  then  the  last  half  of  the  sync 
waveform  will  have  an  apparent  width  of  two  clock  periods  due  to  the 
Manchester  encoding. 

4. 2. 3. 5. 1.2  Address.  The  next  five  bits  following  the  sync  shall  be 
the  RT  address.  This  permits  a maximum  of  32  RTs  to  be  attached  to  any 
one  data  bus.  All  l's  shall  indicate  a decimal  address  of  31,  and  all 
0's  shall  indicate  a decimal  address  of  32.  The  most  significant  bit  of 
the  address  shall  be  transmitted  first. 

4. 2. 3. 5. 1.3  Transmit/receive.  The  next  bit  following  the  address  shall  be 
the  transmit/receive  bit,  which  shall  indicate  the  action  required  of  the 
RT.  A logic  zero  shall  indicate  the  RT  is  to  receive,  and  a logic  one 
shall  indicate  the  RT  is  to  transmit. 
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4. 2. 3. 5. 1.4  Subaddress/mode . The  next  five  bits  following  the  transmit/ 
receive  bit  shall  be  utilized  for  either  a RT  subaddress  or  mode  control, 
as  is  dictated  by  the  individual  terminal  requirements.  The  subaddress/ 
mode  value  of  00000  is  reserved  for  special  purposes,  as  specified  in 
4.2. 3. 5. 1.7,  and  shall  not  be  utilized  for  any  other  function. 

4. 2. 3. 5. 1.5  Word  count.  The  next  five  bits  following  the  subaddress/mode 
control  shall  be  the  quantity  of  data  words  to  be  either  sent  out  or  received 
by  the  RT.  A maximum  of  32  data  words  may  be  transmitted  or  received  in  any 
one  message  block.  All  l's  shall  indicate  a decimal  count  of  31,  and  all 
0's  shall  indicate  a decimal  count  of  32. 

4. 2. 3. 5. 1.6  Parity.  The  last  bit  in  the  word  shall  be  used  for  parity  over 
the  preceding  sixteen  bits.  Odd  parity  shall  be  utilized. 

4. 2. 3. 5. 1.7  Optional  mode  control.  For  RTs  exercising  this  option,  a 
subaddress/mode  code  of  00000  shall  imply  that  the  contents  of  the  word 
count  field  are  to  be  decoded  as  a five  bit  mode  command.  When  used  with 
this  option,  the  word  count  field  mode  code  of  00000  shall  be 

reserved  for  dynamic  bus  allocation. 

4. 2. 3. 5. 2 Data  word.  A data  word  shall  be  comprised  of  a sync  waveform, 
data  bits,  and  a parity  bit  (see  figure  3). 

4. 2. 3. 5.  2.1  Sync.  The  data  sync  waveform  shall  be  an  invalid  Manchester 
waveform  as  shown  on  figure  5.  The  width  shall  be  three  bit  times,  with 
the  waveform  being  negative  for  the  first  one  and  one-half  bit  times, 
and  then  positive  for  the  following  one  and  one-half  bit  times.  Note  that 
if  the  bits  preceding  and  following  the  sync  are  logic  ones,  then  the 
apparent  width  of  the  sync  waveform  will  be  increased  to  four  bit  times. 

4. 2. 3. 5. 2. 2 Data . The  sixteen  bits  following  the  sync  shall  be  utilized 
for  data  transmission  as  specified  in  4.2.2. 

4. 2. 3. 5. 2. 3 Parity.  The  last  bit  shall  be  utilized  for  parity  as  specified 
in  4. 2. 3. 5. 1.6. 

4. 2. 3. 5. 3 Status  word.  A status  word  shall  be  comprised  of  a sync  waveform, 
RT  address,  message  error  bit,  status  codes,  terminal  flag  bit,  and  a 
parity  bit  (see  figure  3). 

4. 2. 3. 5. 3.1  Sv_nc_.  The  sync  waveform  shall  be  as  specified  in  4. 2. 3. 5. 1.1. 
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Figure  6.  Message  Formats 
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4. 2. 3. 5. 3. 2 RT  address.  The  next  five  bits  following  the  sync  shall 
contain  the  address  of  the  terminal  which  is  transmitting  the  status 
word  as  defined  in  4. 2. 3. 5. 1.2. 

4. 2. 3. 5. 3. 3 Message  error.  The  first  bit  after  the  address  shall  be 
utilized  to  indicate  that  the  preceding  message  failed  to  pass  the  RT's 
validity  tests.  This  error  condition  shall  include  parity  errors.  A 
logic  one  shall  indicate  the  presence  of  a message  error,  and  a logic 
zero  its  absence.  A message  error  shall  be  indicated  when  the  preceding 
message  to  a RT  has  failed  either  the  word  or  message  validity  criteria  for 
the  RT.  The  criteria  shall  include  those  specified  in  4. 2. 5. 4. 4. 

4. 2. 3. 5. 3. 4 Status  codes.  The  next  nine  bits  following  the  message  error 
bit  may  be  utilized  in  any  fashion  desired  by  the  RT  designer,  except 
that  all  zeros  shall  indicate  a normally  functioning  terminal. 

4. 2. 3. 5. 3. 5 Terminal  flag.  The  next  to  least  significant  bit  in  the 
status  word  is  reserved  for  a terminal  flag  bit.  This  bit  shall  be  set  to 
one  to  indicate  the  need  for  the  bus  controller  to  examine  the  built  in 
test  data  available  from  the  terminal. 

4. 2. 3. 5. 3. 6 Parity.  The  last  bit  shall  be  utilized  for  parity  as 
specified  in  4. 2. 3. 5. 1.6. 

4. 2. 3. 6 Message  formats.  The  messages  transmitted  on  the  data  bus 
shall  be  '.i  accordance  with  the  formats  in  figure  6.  The  maximum  and 
minimum  response  times  shall  be  as  stated  in  4.3.1. 

4. 2. 3. 6.1  Controller  to  RT  transfers.  The  controller  shall  issue  a 
receive  command  followed  by  the  specified  number  of  data  words.  The  RT 
shall,  after  message  validation,  transmit  a status  word  back  to  the 
controller.  The  command  and  data  words  shall  be  transmitted  in  a continuous 
fashion  with  no  interword  gaps. 

4. 2. 3. 6. 2 RT  to  controller  transfers.  The  controller  shall  issue  a 
transmit  command  to  the  RT.  The  RT  shall,  after  command  verification, 
transmit  a status  word  back  to  the  controller,  followed  by  the  specified 
number  of  data  words.  The  status  and  data  words  shall  be  transmitted  in  a 
continuous  fashion  with  no  interword  gaps. 

4. 2. 3. 6. 3 RT  to  RT  transfers.  The  controller  shall  issue  a receive  command 
to  RT  A,  followed  by  a transmit  command  to  RT  B.  RT  B shall  then  transmit  th 
data  as  specified  in  4. 2. 3. 6.1. 
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.2.4  Transmission  line.  The  data  bus  s 
(medium,  a twisted,  shielded,  wire  pair. 


1 utilize,  as  the  transmission 


.2.4.1  Cable.  The  cable  used  shall  be  a two  conductor,  twisted j shielded , 
..acketed  cable.  The  wire-to-wire  distributed  capacitance  shall  not  exceed 
>0.0  picofarads  per  foot.  The  cable  shall  be  formed  with  not  less  than 
jne  twist  per  inch;  and  the  cable  shield  shall  provide  a minimum  of  80 
percent  coverage. 


4. 2. 4. 2 Characteristic  impedance.  The  characteristic  impedance  shall  be 
70  ohms,  plus  or  minus  10  percent,  at  a sinusoidal  frequency  of  1.0  MHz. 

4. 2.4. 3 Cable  attentuation.  At  the  frequency  of  4. 2. 4. 2,  the  cable  power 
loss  shall  be  1 db/100  ft  or  less. 


4. 2. 4. 4  Cable  length.  The  cable  length  of  any  main  bus  may  be  up 
to  300  feet. 


/ 


4. 2. 4. 5 Cable  termination.  The  cable  shall  be  coupled  to  the  RT  as  shown 
on  figure  7.  A long  stub  is  defined  as  any  stub  greater  than  one  foot  in 
length.  The  use  of  long  stubs  is  discouraged  and  the  length  of  any  stub 
shall  not  exceed  20  feet.  The  two  ends  of  the  cable  shall  be  terminated  with 
a resistance  equal  to  the  cable  characteristic  impedance. 

4. 2. 4. 6 Cable  coupling.  All  connections  to  the  data  bus  shall  utilize 
a small  shielded  coupler  box.  This  box  shall  be  of  sufficient  size  to 
permit  the  installation  of  the  transformer  and  isolation  resistors  specified 
in  4.2.5.  The  connector  plug  shall  be  compatible  with  Amphenol  Type  31-235 
or  Trompeter  Type  TEI-14949-EI37  receptacles.  The  connector  receptacle  shall 
be  compatible  with  Amphenol  type  31-224  or  Trompeter  Type  TEI-1 4949-PL36  plugs. 
The  polarity  convention  shall  be  that  the  female  connection  in  the  plug  is 
positive,  and  the  male  connection  in  the  receptacle  is  positive.  This 
connector,  with  the  indicated  polarities,  shall  be  used  for  all  bus  interfaces. 

4. 2. 4. 7 Wiring  and  cabling  for  EMC.  For  purposes  of  electromagnetic 
compatibility  (EMC),  the  wiring  and  cabling  provisions  of  MIL-E-6051 
shall  apply. 

4.2.5  RT/bus  interface  circuits. 

4. 2. 5.1  Circuit  configuration.  The  input/output  circuits  shall  consist 
of  a transmitter-receiver,  DC  isolation/coupling  transformer,  and  isolation 
resistors  as  configured  on  figure  7. 
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.2.5.2  Fault  isolation.  An  isolation  resistor  shall  be  placed  in  series 
Vith  each  connection  to  the  data  bus  cable.  This  resistor  shall  have  a 
value  of  0.75  Z ohms  plus  ur  minus  5 percent  where  Z is  the  cable 
Characteristic  impedance.  The  impedance  placed  across  the  data  bus 
C^ble  shall  be  no  less  than  1.5  Z ohms  for  any  failure  of  the  coupling 
transformer,  cable  stub,  or  RT  transmitter/receiver. 

. 2-.  5 . 3 RT  output  characteristics. 

A. 2. 5. 3.1  Output  levels.  The  RT  signal  output  circuitry  shall  be  capable 
of  driving  the  cable  specified  in  A.2.A.1  and  not  less  than  33  other  RTs, 
as  specified  herein,  each  attached  to  the  cable  by  means  of  a cable  stub 
of  maximum  length  specified  in  A. 2. A. 5.  The  output  circuitry  shall  maintain 
the  specified  operation  with  the  exception  of  a 25  percent  maximum  reduction 
of  the  data  bus  signal  amplitude  in  the  event  that  one  of  the  RTs  has  a 
fault  that  causes  it  to  reflect  the  fault  impedance  specified  in  A. 2. 5. 2 
on  the  bus.  The  RT  peak  signal  output  voltage  shall  be  between  plus  or  minus 
3.0  and  10.0  volts,  line-lo-line,  when  measured  at  the  data  bus  cable 
connection  (point  A on  figure  7). 

A. 2. 5. 3. 2 Output  wavetorm.  The  waveform  when  observed  at  point  C in 
figure  7 shall  have  zero  crossings  which  deviate  not  more  than  plus  or  minus 
25  nanoseconds  from  those  shown  in  figure  8.  The  rise  and  fall  time  of 
this  waveform  shall  be  equal  to  or  greater  than  100  nanoseconds  when 
measured  from  levels  of  10  to  90  percent  of  full  waveform  peak-to-peak, 
voltage  as  shown  in  figure  8. 

A. 2. 5. 3. 3 Output  noise.  Any  noise  transmitted  to  the  data  bus  when  the  RT  is 
receiving  or  has  power  removed,  shall  not  exceed  a value  of  10.0  millivolts 
peak-to-peak,  line-to-line,  as  measured  at  the  point  specified  in  A. 2. 5. 3.1. 

A. 2. 5. A RT  input  characteristics. 

A.2.5.A.1  Input  waveform  compatibility.  The  RT  shall  be  capable  of 
receiving  and  operating  with  the  incoming  signals  specified  herein,  and 
shall  accept  waveforms  varying  from  a square  wave  to  a sine  wave.  The 
RT  shall  respond  to  an  input  signal  whose  positive  or  negative  peak  amplitude, 
line-to-line,  is  within  the  range  of  10.0  to  0.5  volts.  The  voltages 
are  measured  at  point  C in  figure  7. 

A. 2. 5. A. 2 Common  mode  re lections.  Any  signals  from  dc  to  2.0  MHz, 
with  amplitudes  equal  to  or  less  than  plus  or  minus  10.0  volts  peak, 
line- to-ground,  applied  to  point  A as  shown  in  figure  7 shall  not  degrade 
the  performance  of  the  RT. 
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4. 2. 5. 4. 3 Input  impedance.  The  magnitude  of  the  RT  input  impedance,  when 
the  RT  is  not  transmitting,  or  has  power  removed,  shall  be  a minimum 

of  2000  ohms  within  the  frequency  range  of  100  KHz  to  1.0  MHz.  This 
impendance  is  that  measured  line-to-line  at  point  C on  figure  7. 

4. 2. 5.4.4  Data  validation.  Logic  shall  be  provided  in  each  RT  to 
recognize  improperly  coded  signals,  data  dropouts,  or  excessively  noisy 
signals.  Each  word  shall  conform  to  the  following  minimum  validating 
criteria; 

a.  The  word  begins  with  a valid  sync  field 

b.  The  bits  are  in  a valid  Manchester  II  code 

c.  The  information  field  has  16  bits  plus  parity 

d.  The  word  parity  is  odd. 

Where  a word  fails  to  conform  to  the  preceding  criteria,  the  word  shall 
be  considered  invalid  and  shall  not  be  used  by  the  receiving  RT.  Where 
an  Invalid  word  sync  occurs,  the  receiving  RT  shall  reset  and  wait  for  a 
new  valid  message  sync.  An  invalid  word  count  shall  be  construed  as  a 
message  transmission  error. 

4.3  Terminal  operation.  The  remote  terminal  shall  operate  in  response 
to  commands  received  from  the  bus  controller.  The  RT  shall  be  capable  of 
receiving  a command  word  at  any  time  except  when  it  is  transmitting.  A 
second  command  word  sent  to  a terminal  after  it  is  already  operating  on 
one  shall  invalidate  the  first  command  and  cause  the  RT  to  begin  operation 
on  the  second  command. 

4.3.1  Response  time.  The  RT  shall  respond  to  a valid  transmit  data  command 
during  the  time  period  2.0  to  5.0  microseconds  after  receipt  of  the  last  bit 
of  the  command  word.  The  RT  shall  respond  to  a valid  receive  data 
comnand  during  the  time  period  2.0  to  5.0  microseconds  after  receipt  of  the 
last  bit  of  the  last  data  word. 

4.3.2  Terminal  fail-safe  operation.  The  RT  shall  contain  the  self-test 
circuitry  necessary  to  detect  an  erroneous  transmission  of  data  on  to  the 
data  bus.  This  circuitry  shall  include  a transmission  time-out  which 
will  preclude  a signal  transmission  period  of  greater  than  660  microseconds 
(one  status,  and  thirty -two  data  words).  When  the  self-test  circuitry 
detects  any  such  erroneous  transmission,  it  shall  automatically  shut 

down  the  transmitter  portion  of  the  RT. 
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4.3.3  Noise  environment  operation.  The  remote  terminal  shall  function 
properly  under  the  test  conditions  specified  in  4.3. 3.4,  and  encountering 
the  electromagnetic  environment  specified  in  4. 3.3.1.  The  remote  terminal 
shall  exhibit  a maximum  bit  error  rate  of  10-^ f where  the  bit  error  rate 
is  as  defined  in  4. 3. 3. 2.  The  remote  terminal  shall  also  exhibit  a maximum 
incomplete  message  rate  of  10-6,  where  the  incomplete  message  rate  is  as 
defined  in  4. 3. 3. 3. 

4. 3. 3.1.  Test  environment.  The  test  environment . for  the  remote  terminal 
and  data  bus  cable  radiated  susceptibility  shall  be  as  follows: 

4. 3. 3. 1.1  Electric  field.  The  electric  field  test  shall  employ  MIL-STD-462 
method  RS03»  with  the  limit  specified  in  MIL-STD-461  test  limit  RS03. 

The  electric  field  shall  be  100  percent  modulated  by  a waveform  as  specified 
in  4.2.3. 

4.3.3. 1.2  Magnetic  field.  The  magnetic  field  (spike  test)  shall  employ 
MIL-STD-462  method  RS02,  with  the  limit  specified  in  MIL-STD-461  test  limit 
RS02. 

4. 3. 3. 2 Bit  error  rate.  For  the  purposes  of  paragraph  4.3.3,  the  bit  error 

rate  is  defined  as  follows:  The  bus  controller  transmits  32  data  words  to  a 

remote  terminal  as  specified  in  4.1,  and  the  remote  terminal  responds  with 

a status  word  indicating  no  message  errors.  The  bus  controller  then  commands 
the  remote  terminal  to  transmit  the  same  32  data  words  which  it  previously 
received,  as  is  specif ed  in  4.1.  Upon  receipt  of  a valid  response  from  the 
remote  terminal,  the  controller  than  compares  each  data  word  which  it  sent 
to  the  remote  terminal  '..ith  each  one  it  received  back  from  the  remote  terminal. 
The  sixteen  bits  in  each  word  pair  are  compared  and  if  any  bit  does  not 
match,  this  is  to  be  considered  a bit  error.  The  total  number  of  data  bits 
transmitted  during  a specific  time  period  are  counted.  The  bit  error  rate 
is  then  defined  as  the  number  of  bit  errors,  divided  by  the  total  number 
of  bits  transmitted. 


4. 3. 3. 3  Incomplete  message  rate.  For  the  purposes  of  paragraph  4.3.3,  the 
incomplete  message  rate  is  defined  as  follows:  A message  is  the  set  of 

command,  data,  and  status  words  as  defined  in  4. 2. 3. 6.  An  incomplete 
message  is  defined  as  one  during  which  the  remote  terminal  does  not  properly 
respond  to  a command  by  the  bus  controller,  or  one  in  which  the  message  error 
bit  is  set  in  the  remote  terminal  status  word.  The  total  number  of  incomplete 
messages  are  counted  during  a specific  time  period,  as  are  the  total  number 
of  messages.  The  incomplete  message  rate  is  given  by  the  number  cf  incomplete 
messages  divided  by  the  total  number  of  messages.  The  message  error  bit  in 
the  f irst  status  word  following  a non-response  by  a remote  terminal  shall 
not  be  included  in  the  incomplete  message  count.  The  message  formats  shall 
be  as  defined  in  4. 3. 3. 2. 
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4. 3. 3. 4 Teat  conditions.  For  purposes  of  the  noise  tests,  the  following 
conditions  shall  be  observed.  All  data  words  shall  be  changed  to  random 
bit  patterns  prior  to  each  transmission/reception  set  as  defined  in  4. 3. 3. 2. 

The  test  3hall  be  conducted  with  the  bus  controller  and  the  remote  terminal 
both  connected  by  20  foot  stubs  to  the  main  data  bus  cable,  with  a minimum 
distance  of  100  feet  between  the  stubs.  The  remote  terminal  transmitter  shall 
provide  an  output  as  specified  in  4. 2. 5. 3.  The  bus  controller  transmitter 
shall  have  its  output  adjusted  so  as  to  provide  the  minimum  signal  amplitude 
specified  in  4. 2. 5. 4.1  at  the  remote  terminal. 

4.4  Terminal  to  subsystem  interface.  For  those  applications  where  a terminal 
is  not  contained  within  a subsystem,  and  the  terminal  exists  as  a distinct  LRU, 
the  terminal  shall  provide  the  necessary  electronics  to  interface  to  the 
subsystem.  The  terminal  shall  have  provisions  for  the  standard  serial 
digital  and  discrete  interfaces  as  defined  in  the  following  paragraphs. 

All  other  signals  shall  require  special  purpose  interface  provisions 
within  the  terminal,  this  electronics  being  designed  for  the  peculiar 
interface  requirement. 

4.4.1  Serial  digital  interface.  The  standard  serial  digital  interface 
shall  be  configured  as  shown  in  figure  9.  All  lines  are  unidirectional, 
with  the  data  line's  direction  to  be  determined  by  its  usage,  i.e.,  to 
transmit  or  to  receive  data.  The  Interface  shall  operate  as  defined  in 

4. 4. 1.1  for  an  input  Interface  and  as  defined  in  4.4. 1.2  for  an  output 
interface.  The  functions  of  each  of  the  signals  is  as  defined  in  table  I. 

4.4. 1.1  Serial  digital  input.  A serial  digital  input  interface  is  a set 
ot  six  signals  between  an  external  device  and  the  remote  terminal.  This 
interface  is  shown  in  figure  10.  The  function  of  each  of  the  six  signals 
is  defined  in  table  I.  The  performance  of  a data  input  sequence  can  be 
initiated  by  either  of  two  actions.  The  external  device  can  pulse  the  FLAG 
line  if  the  LOCKOUT  line  is  low,  and  thereby  initiate  a data  input  sequence. 

The  timing  diagram  for  this  action  is  shown  in  figure  11.  The  bus  controller 
can  directly  command  the  remote  terminal  to  begin  a data  input  sequence.  The 
timing  diagram  for  this  action  is  shown  in  figure  12.  In  either  case,  the 
initiation  of  the  data  input  sequence  causes  the  LOCKOUT  line  to  be  set,  and 
the  completion  of  the  data  input  sequence  shall  cause  the  remote  terminal 
to  notify  the  bus  controller  of  the  data  input,  and  of  any  parity  errors. 

The  remote  terminal  shall  be  required  to  clear  the  LOCKOUT  before  any  new 
externally  initiated  data  input  sequences  can  occur. 
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FIGURE  9;  Serial  Digital  Interface 
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TABLE  I 

Signal  Definitions  for  Serial  Digital  Interfaces 

1.  REQUEST.  This  is  a signal  from  the  remote  terminal  to  the  external 
device  which,  when  set  to  logic  1 by  the  remote  terminal,  notifies  the 
external  device  that  a data  transfer  is  about  to  take  place,  and  when 
set  to  logic  0 by  the  remote  terminal,  notifies  the  external  device  that 
a data  transfer  is  complete. 

2.  ACKNOWLEDGE.  This  is  a signal  from  the  external  device  to  the 

remote  terminal  which,  when  set  to  logic  1 by  the  external  device,  notifies 
the  remote  terminal  that  the  external  device  has  recognized  the  REQUEST,  and 
is  ready  for  the  data  transfer,  and  when  set  to  logic  0 by  the  external 
device,  notifies  the  remote  terminal  that  the  external  device  has  recognized 
the  lowering  of  the  REQUEST  and  the  end  of  the  data  transfer. 

3.  CLOCK.  This  is  a signal  from  the  remote  terminal  to  the  external 
device,  which  when  active  is  a 1 MHz  square  wave,  with  a number  of  cycles 
equal  to  the  number  of  bits  to  be  shifted.  The  CLOCK  is  not  started  until 
the  remote  terminal  has  seen  the  ACKNOWLEDGE  line  raise.  At  the  end  of  the 
last  CLOCK  cycle  the  remote  terminal  shall  lower  the  REQUEST  Line. 

4.  DATA.  This  is  a signal  to  or  from  the  remote  terminal  upon  which  data 
is  transmitted.  On  the  positive  edge  of  the  CLOCK  signal  the  next  DATA 
bit  shall  be  placed  on  the  DATA  line. 

5.  LOCKOUT . This  is  a signal  from  the  remote  terminal  to  the  external 
device  which,  when  set  to  logic  1 by  the  remote  terminal,  notifies  the 
external  device  that  it  shall  refuse  all  external  requests  for  data 
transfer,  and  when  set  to  logic  0 by  the  remote  terminal,  notifies  the 
external  device  that  it  shall  allow  external  requests  for  data  transfer. 

6.  ERROR . This  is  a signal  from  the  external  device  to  the  remote 
terminal  which  the  external  device  clears  at  the  time  ACKNOWLEDGE  is 
raised,  and  which  the  external  device  sets  at  any  time  that  a parity 
error  is  detected  while  receiving  data. 

7.  FLAG.  This  is  a signal  from  the  external  device  to  the  remote  terminal, 
which  is  a pulse  of  duration  between  1 and  10  microseconds,  that  notifies  the 
remote  terminal  that  there  has  been  an  external  request  for  a DATA  input  sequence. 
The  occurrence  of  this  pulse  shall  initiate  a DATA  input  sequence,  and  after 

the  sequence  is  completed  the  bus  controller  shall  be  informed  that  the 
sequence  occurred  and  whether  or  not  there  were  any  parity  errors.  This  signal 
cannot  occur  while  the  LOCKOUT  line  is  high,  and  the  occurrence  of  this 
signal  causes  the  LOCKOUT  line  to  be  set  high. 
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Figure  10.  Serial  Digital  Input  Interface 
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Figure  11.  Serial  Digital  Input  Interface  Timing  Diagram 
for  External  Initiation  of  Transfer 

OTE:  (1)  N equals  17  times  the  number  of  words 

(2)  tj  Is  less  than  10  and  greater  than  1 microsecond 

(3)  tj,  tj  and  t*  arc  less  than  200  nanoseconds 

(4)  t«  is  less  than  SOO  nanoseconds 

(5)  t(  Is  design  dependent 
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NOTE:  (1)  N equals  17  times  the  number  of  words 

(2)  tj  and  t3  are  less  than  20C  nanoseconds 

(3)  t2  Is  less  than  500  nanoseconds 

(4)  ti,  Is  design  dependent 
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Figure  12.  Serial  Digital  In£ut  Interface  Timing  Diagram 
for  Terminal  Initiation  of  Transfer 
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4. 4. 1.2  Serial  digital  output.  A serial  digital  output  interface  is  a 
set  of  five  signals  between  an  external  device  and  the  remote  terminal. 

This  Interface  is  shown  in  figure  13.  The  functions  of  each  of  these 
five  signals  is  defined  in  table  I.  The  timing  diagram  for  the  data  output 
sequence  using  these  five  signals  is  shown  in  figure  14.  The  performance 
of  a data  output  sequence  can  be  initiated  by  either  of  two  bus  controller 


actions.  The  bus  controller  can  send  a new  data  block  to  the  remote 
terminal,  and  the  receipt  of  this  data  block  shall  initiate  a data  output 
sequence.  The  bus  controller  can  also  directly  command  the  remote  terminal 
to  begin  a data  output  sequence  using  the  data  block  that  the  remote  terminal 
has  available.  In  either  case,  once  a data  output  sequence  is  Initiated,  the 
serial  Interface  shall  always  transfer  the  complete  set  of  data,  and  when  the 
data  transfer  is  complete  the  remote  terminal  shall  examine  the  ERROR  line. 

4.4. 1.3  Signal  characteristics.  The  characteristics  of  serial  digital 
signals  shall  be  in  accordance  with  the  following: 

a. 

Data  code 

Non-return-to  zero  (NRZ) 

b. 

Type 

Differential  and  balanced 

c. 

Data  word 

16  bits  followed  by  one  bit  of  odd  parity 

d. 

Data  rate 

One  megabit  plus  or  minus  10  percent 

e. 

Rise  and  fall  time 

As  specified  in  4. 2. 5.3. 2 

f. 

Output  voltage 

Zero:  -0.5  to  0.5  volts 

One:  2.4  to  5.5  volts 

8- 

Conmon  mode  output 
voltage 

The  common  mode  output  voltage  (measured  from  each 
line  to  the  signal  common)  of  the  output  circuit 
shall  be  no  greater  than  plus  or  minus  0.5  volt  peak 

h. 

Short  and  Over- 
voltage protection 

The  output  circuit  shall  not  be  damaged  when 
subjected  to  shorts  to  ground  or  a voltage  of  plus 
or  minus  20  volts 

i. 

Message  size 

A fixed  number  of  words  for  each  request  with  a 
maximum  of  32  words 

J- 

Bit  priority 

As  specified  in  4.2.2. 

{ I 
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Figure  13.  Serial  Digital  Output  Interface 
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4.4.2  Discrete  signals.  The  discrete  interface  shall  be  double-ended, 
and  shall  employ  the  following  logic  levels: 

Zero:  -0.5  to  0.5  volts 

One:  2.4  to  5.5  volts 

The  input  circuits  shall  present  a minimum  impedance  of  10K  ohms. 

Overvoltage  faults  to  an  input  of  up  to  plus  or  minus  20  volts  shall  not 
damage  the  input.  The  output  circuits  shall  be  capable  of  providing  a 
minimum  output  current  of  100  milliamperes . Short  circuits  on  either  inputs 
or  outputs  shall  not  damage  the  circuits. 

4.5  Bus  controller.  The  controller  shall  be  responsible  for  sending  data 
bus  commands,  participating  in  data  transfer,  receiving  status  response 
and  monitoring  system  status  as  defined  in  this  standard.  The  controller 
may  be  embodied  as  either  a stand  alone  hardware  unit  whose  sole  function 
is  to  control  the  data  bus(s),  or  contained  within  the  I/O  section  of 
an  airborne  computer.  The  controller  shall  be  programmable  and  shall 
operate  under  software  (or  firmware)  control.  Individual  application 
requirements  shall  determine  the  choice  as  to  which  form  of  controller 
is  used. 
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APPENDIX 


10.  General.  The  following  paragraphs  in  this  appendix  are  presented  in 
order  to  discuss  certain  aspects  of  the  standard  in  a general  sense. 

They  are  intended  to  provide  a user  of  the  standard  more  insight  into 
the  aspects  discussed. 

10.1  Redundancy.  It  is  intended  that  this  standard  be  used  to  support 
rather  than  to  supplant  the  system  design  process.  For  this  reason,  the 
standard  is  deliberately  vague  concerning  the  use  of  redundancy  in 
implementing  a multiplex  data  bus  system.  The  system  designer  should 
utilize  this  standard  as  the  needs  of  a particular  application  dictate. 

The  use  of  redundancy,  the  degree  to  which  it  is  implemented,  and  the  form 
which  it  takes  must  be  determined  on  an  individual  application  basis. 

Figures  10.1  and  10.2  illustrate  some  possible  approaches  to  dual  redundancy. 
These  illustrations  are  not  intended  to  be  inclusive,  but  rather  representative. 
It  should  be  noted  that  analogous  approaches  exist  for  the  triple  and  quad 
redundant  cases. 

10.2  Bus  controller.  The  bus  controller  is  a key  part  of  the  data  bus 
system.  The  functions  of  the  controller,  in  addition  to  the  issuance 

of  commands,  must  include  the  constant  monitoring  of  the  data  bus  and  the 
traffic  on  the  bus.  It  is  envisioned  that  most  of  the  routine  minute  details 
of  bus  monitoring  (e.g.,  parity  checking,  terminal  non-response  time-out, 
etc.)  will  be  embodied  in  hardware,  while  the  algorithms  for  bus  control  and 
decision  making  will  reside  in  software.  It  is  also  envisioned  that,  in 
general,  the  bus  controller  will  be  a general  purpose  airborne  computer 
with  a special  input/output  (T/0)  unit  to  interface  with  the  data  bus. 

In  the  case  of  a large  aircraft,  such  as  a bomber,  the  multiplex  bus  control 
problem  may  be  of  sufficient  complexity  to  warrant  the  employment  of  a 
dedicated  bus  controller.  While  in  a smaller,  fighter-type  aircraft, 
the  control  function  will  probably  be  incorporated  into  a computer  which 
is  also  utilized  for  the  navigation  and  weapon  delivery  functions.  It  is 
important  to  remember  that  the  controller  will  be  the  focal  point  for 
modification  and  growth  within  the  multiplex  system,  and  thus  the  software 
must  be  written  in  such  a manner  as  to  permit  modification  with  relative 
ease. 
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FIGURE  10.1 


FIGURE  10.2 

NOTE:  RT  - Remote  Terminal 


ILLUSTRATIONS  OF  POSSIBLE  REDUNDANCY 
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10.3  Multiplex  selection  criteria.  The  selection  of  candidate 
signals  for  multiplexing  is  a function  of  the  particular  application 
involved,  and  criteria  will  in  general  vary  from  system  to  system. 

Obviously  those  signals  which  have  bandwidths  of  400  Hz  or  less  are  prime 
candidates  for  inclusion  on  the  bus.  It  is  also  obvious  that  video,  audio, 
and  high  speed  parallel  digital  signals  should  be  excluded.  The  area  of 
questionable  application  is  usally  between  400  Hz  and  3kHz  bandwidth. 

The  transfer  of  these  signals  on  the  data  bus  will  depend  heavily  upon 
the  loading  of  the  bus  in  a particular  application.  The  decision  must  be 
based  on  projected  future  bus  needs  as  well  as  the  current  loading.  Another 
class  of  signals  which  in  general  are  not  suitable  for  multiplexing  are  those 
which  can  be  typified  by  a low  rate  (over  a mission)  but  possessing  a high 
priority  or  urgency.  Examples  of  such  signals  might  be  a nuclear  event 
detector  output  or  a missile  launch  alarm  from  a warning  receiver.  Such 
signals  are  usually  better  left  hardwired,  but  they  may  be  accommodated  by 
the  multiplex  system  if  a direct  connection  to  the  bus  controller's  interrupt 
hardware  is  used  to  trigger  a software  action  in  response  to  the  signal. 

10.4  High  reliability  requirements.  The  use  of  simple  parity  for  error 
detection  within  the  multiplex  bus  system  was  dictated  by  a compromise 
between  the  need  for  reliable  data  transmission,  system  overhead,  and  remote 
terminal  simplicity.  Theoretical  and  empirical  evidence  Indicates  that  an 
undetected  bit  error  rate  of  10-*2  can  be  expected  from  a practical  multiplex 
system  built  to  this  standard.  If  a particular  signal  requires  a bit  error 
rate  which  is  better  than  that  provided  by  the  parity  checking,  then  it  is 
incumbent  upon  the  system  designer  to  provide  the  reliability  within  the 
constraints  of  the  standard  or  to  not  include  this  signal  within  the  multiplex 
bus  system.  A possible  approach  in  this  case  would  be  to  have  the  signal 
source  and  sink  provide  appropriate  error  detection  and  correction  encoding/ 
decoding  and  employ  extra  data  words  to  transfer  the  information.  Another 
approach  would  be  to  partition  the  message,  transmit  a portion  at  a time,  and 
then  verify  (by  interrogation)  the  proper  transfer  of  each  segment. 

10.5  Stubbing.  Stubbing  is  a method  wherein  a separate  line  is  connected 
between  the  primary  data  bus  line  and  a remote  terminal.  The  direct 
connection  of  a stub  line  causes  a mismatch  which  appears  on  the  waveforms. 
This  mismatch  can  be  reduced  by  filtering  at  the  receiver  and  by  using 
Biphase  modulation.  Stubs  are  often  employed  not  only  as  a convenience 

in  bus  layout  but  as  a means  of  coupling  a unit  to  the  line  in  such  a manner 
that  a fault  on  the  stub  or  terminal  will  not  greatly  affect  the  transmission 
line  operation.  In  this  case,  a network  is  employed  somewhere  in  the  stub 
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line  to  provide' isolation  from  the  fault.  These  networks  are  also  used 
for  stubs  that  are  of  such  length  that  the  mismatch  and  reflection  degrades 
bus  operation.  Of  the  possible  networks,  transformer  coupling  gives  the 
least  loss.  For  a 300  foot  transmission  line  operating  at  1 megabit, 
the  total  loss  for  the  system  with  30  stubs  was  between  19  and  25  dB.  For 
other  networks  such  as  direct,  loss,  and  loaded,  the  loss  varied  from 
32  to  45  dB.  If  the  length  of  the  stub  does  not  approach  one-quarter 
wavelength  or  is  less  than  50  cm,  it  does  not  seem  to  cause  significant 
distortion.  It  may  be  well  to  note  that  stubbing  is  not  a preferred  method 
of  bus  conf iguation,  but  that  it  is  necessary  or  convenient  in  the  physical 
layout  or  Installation  of  the  transmission  line.  The  exact  limit  to  stubbing 
depends  upon  the  number  of  stubs,  length,  type  of  modulation,  and  the  degree 
of  filtering  used. 

10.6  Status  code  usage.  The  nine  bits  in  the  remote  terminal  status  word 
allocated  for  Status  Codes  may  be  utilized  in  any  manner  the  terminal 
designer  wishes.  Such  usage  may  include  the  following  possibilities: 

10.6.1  Vectored  service  request.  These  nine  software  interpretable 

bits  may  be  used  to  encode  a subaddress  and  word  count  referencing  a specific 
set  of  data  words  wllch  the  terminal  wishes  to  have  collected  by  the  bus 
controller.  All  zeros  in  the  field  could  signify  no  requests. 

10.6.2  Error  code  supplement.  The  nine  bits  could  be  used  in  a manner 
similar  to  that  discussed  in  10.6.1,  but  rather  providing  references  to 
subaddressed  data  words  relating  to  message  errors  or  terminal  flags. 

These  referenced  words  might  then  contain  more  detailed  information 
such  as  parity  errors,  word  count  errors,  encoding  errors,  power  supply 
failures,  interfaces  subsystem  failure,  etc. 

10.6.3  Assigned  codes.  The  individual  bit  positions  may  be  assigned  specific 
error  code  significance.  Thus,  if  one  bit  is  set,  then  a power  supply  failure 
is  indicated,  or  if  another  bit  is  set,  then  a Manchester  encoding  error  has 
occurred. 
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